Iteration 7: Blackbox Testing and Pattern Hunting

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 goal is to use equivalence-class partitioning as technique to develop high quality test cases, and to apply a set of design patterns from the FRS catalog to your HotCiv design.


Solve and document exercises:

  1. FRS 36.48 / Systematic test of 'moveUnit()'
  2. Early release FRS 36.50 and 36.51 / Systematic test of attack. Read and understand 36.50 and 36.51. You are NOT required to solve this exercise this week, but it becomes a mandatory exercise next week.
  3. FRS 36.29 / Facade
  4. FRS 36.30 / Transcript
  5. Fractal Maps / (Updated version of FRS 36.31)

    Integrate a third party fractal landscape generator into your HotCiv to allow generating the tile landscape, using the Adapter pattern. A demonstration of the third party fractal library can be found here, and a short explanation of the code base can be found in FRS 36.31. Unzip the zip file, and 'gradle demo' in the root of it. To update your gradle dependency in your HotCiv project to include the fractal library, see Note 1 below.

    Note: Depending upon your specific design of DeltaCiv the 'Adapter' pattern may or may not be the proper solution. The exercise is therefore to answer the following questions:

    1. Adapter Pattern Match: Analyse the suitability of a 'Adapter' pattern based design for introducing the supplied ThirdPartyFractalGenerator using a purely "Change by addition" method into your HotCiv.
    2. Implementation Notes: Include and explain code fragments that demonstrate how the fractal generator is used by your HotCiv. Include an integration test (see Note 3 below) that tests that your HotCiv is using the Fractal map generator to produce landscapes.

  6. Optional: FRS 36.25 / Role diagram
  7. Optional: FRS 36.26 / Concept relations
  8. Optional: Bloch's Builder pattern.

    Our HotCiv is using an Abstract Factory to inject the many delegates that configure it. However, the normal use of Abstract Factory is often to continously create objects, such as the creation of receipts in the PayStation: There, receipts are created throughout the lifetime of the running system. In contrast, our HotCiv Abstract Factory is likely only used in the initial configuration of the Game instance.

    Thus, we could consider using Bloch's Builder pattern to configure the Game instead - something along the lines of:

    Game game = new GameImpl.GameBuilder().
      setWinnerStrategy( new RedWinInYear3000WinnerStrategy() ).

    Evaluate whether such a change of injection pattern is feasible for your HotCiv framework. Argue why/why not.

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


  1. Documentation for your work by following the requirements defined in the iteration 7 report template (pdf) (LaTeX source)

Notes and Hints

Note 1

To make your project's build.gradle use the fractal landscape library you need to do this:
  1. Update the repository section to include Bærbak's personal bintray repository:
    repositories {
        // the fractal library is NOT in the official JCenter
        // repository, only in Bærbak's public repository.
        maven {
           url ''
  2. Include a dependency to 'hotciv-fractal' version 1.0:
    dependencies {
      [your existing dependencies here]              
      compile 'com.baerbak.maven:hotciv-fractal:1.0'
  3. I often experience that IntelliJ does not understand, that a new dependency has been added. If you experience the same, you can call up the Gradle View and refresh it: Hit the menu item 'View' -> 'Tools Window' -> 'Gradle'. This will show a new window, and you have to click the 'Refresh' button, as shown below:
    Now, the library is available in your project, and you can use name completion, etc.
  4. If IntelliJ chokes completely and does not understand that it is a Java/Gradle project (as I experience way too often), try 'rebooting' the project as outlined in my IntelliJ tutorial (Section "Panic Button").

Note 2

To solve the 'transcripting' exercise you may either rely on manual testing (see the proper output being printed), or to get automated testing, review the technique using PrintStream in FRS §13.1.

Note 3

Testing that HotCiv is integrated with the fractal maps library correctly is tricky: Fractal maps is using randomness but as it is a third party component we have no chance of introducing test stubs into it. I would normally use a manual test strategy, using the GUI to verify that indeed random maps appear. But, as we do not have a GUI (yet), I will outline an alternative test strategy.

To test that a HotCiv variant probably runs with the fractal generator, I may code an integration test along the lines of

Create a new HotCiv Game 25 times, for each {
  Add tiletype of tile (0,0) to a List
If all entries in the List are the same, the test FAILS
Of course there is a theoretical chance that the fractal generator does generate 25 identical tiles but it is extremely low.

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 7 Grade sheet to evaluate your submission. The score counts towards your final grade.

Learning Goal Assessment parameters
Submission Git repository can be pulled using "Release7". Git repository is not public! Code must compile; 'gradle test jacocoTestReport' must pass; required artefacts (report following the template) are present.
Equivalence Class Partitioning A correct EC partitioning has been made, clearly describing and arguing for the partitioning heuristics used, and documented correctly in an EC table. Coverage and representation properties have been analyzed and discussed.
Test Case Generation A correct set of test cases has been generated using proper application of Myers heuristics and are documented in a proper extended test case table. The TDD test case set is reviewed to see if any obvious omissions are present.
Design Patterns Correct design patterns are selected, the argumentation for choosing them is correct, and they are correctly implemented. The UML outlining the design is correct syntactically and semantically. [The optional Bloch builder is not part of the evaluation.]
Test Code and Clean Code Test code (see note 4 below) validates the developed code (Smoke test for Fractal map is OK, manual test for transcript). 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. Missing features are noted in the backlog.
Optional Exercises All optional exercises are correctly solved and concisely documented.

Note 4. I no longer require you to adhere to the TDD process, but still require that your production code is 'as much as possible' covered/tested by test code.