Iteration 5: Test Stubs and More Patterns

Deadline

Always at 23.59 on the same day as your TA session (Except Monday classes).

Consult the deadline for your class on the delivery plan.

Learning Goals

In this iteration, the learning goals are using test stubs to get "randomness" under automated test control; and applying the State and Abstract Factory patterns.

Exercise

Solve and document FRS exercises:

And release them using the tag/branch name "Release5".

Deliveries:

  1. Instead of individual documentation for each exercise as stated in the FRS exercises, you should document your group's work by following the requirements defined in the iteration5 report template (pdf) (LaTeX source)

Notes

Hint: The O function in EpsilonCiv is a highly complex function that takes a lot of input, however, the output (true/false) is not very suitable to establish testing on (it is very easy to get a false positive). Thus, your TDD should focus on test-drive the sub-functions, combined attach strength with suitable test stubbing, and the equivalent for defensive strength.

To lower the implementation burden on EpsilonCiv, you may reuse/refactor fragments/methods from my utility library Utility2.java into your implementation. The associated tests are in TestUtility2.java which reuses the iterator utility methods introduced earlier.

Evaluation criteria

Your submission is evaluated against the learning goals and adherence to the submission guidelines. The grading is explained in Grading Guidelines. The TAs will use the Iteration 5 Grade sheet to evaluate your submission. The score counts towards your final grade.

Learning Goal Assessment parameters
Submission Git repository can be pulled using "Release5". Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; required artefacts (report following the template) must be present.
Test Stub The "randomness" of the attack/defense strength calculations/die roll is properly encapsulated in a test stub using a compositional design. JUnit test cases for EpsilonCiv and/or the attack/defense subfunctions are deterministic and correct. The design is correctly documented in the report.
State Pattern The ZetaCiv winning algorithm is designed and coded using a State pattern. Existing winning strategies from BetaCiv and EpsilonCiv are properly reused by composition (i.e. no source-code-copy reuse, polymorphic reuse, etc.). Decisions on where state is stored (count of attacks won, etc.) are proper and correctly documented in the report.
Abstract Factory Pattern The abstract factory pattern is correctly designed and implemented, and well documented in the report.
UML The UML diagrams are syntactically correct, correctly reflects the patterns/stubs, and is a correct overview of the architecture. The UML diagram does not show irrelevant implementation oriented details. The interfaces shows essential method(s) for the state/factory/stub.
TDD and Clean Code TDD process has been applied. Test code and Production code keeps obeying the criteria set forth in the previous iterations, including adhering to Clean Code properties for newly developed code. The requirements of EpsilonCiv, ZetaCiv, and abstract factory are correctly implemented. Missing features are noted in the backlog (Minor omissions allowed).