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.
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.
Solve and document FRS exercises:
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.
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).|