Iteration 7: Blackbox Testing and Pattern Hunting

Deadline

At 23.59 on the day that your class has agreed with the TA.

Any late hand-in must be agreed with your TA; failing to do so will allow the TA to reject evaluating your hand-in.

Workload Estimate

High

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 HotStone design.

Exercises

Equivalent Class Partitioning of RhoStone 'attack()'

Define a minimal set of test cases for the 'attack(who, card, opp)' function for the RhoStone game (FRS § 37.8.1), using the systematic black-box testing technique equivalence class partitioning.

This is a purely theoretical exercise, RhoStone should not be implemented.

  1. Describe a list of the relevant conditions that influence function 'attack()' ... as outlined in the Iteration 7 report template
  2. Document an equivalence class table that enumerates all your found equivalence classes and briefly argue for the representation property and the set's coverage property...
  3. Outline an extended test case table of concrete test cases defined from the previous analysis, and argue for the heuristics applied to generate them...
... as detailed in the Iteration 7 report template below.

PreRelease: EC test of SigmaStone 'augmentMinion()'

This exercise is not to be handed in until Iteration 9! It is just a pre release so - read it, understand it, and let your subconscience work on it.

Define a minimal set of test cases for the 'augmentMinion(...)' function defined by the SigmaStone game (FRS § 37.8.2), using the systematic black-box testing technique equivalence class partitioning.

Facade

The graphical user interface introduced in the next iteration accesses and modifies the HotStone game's state through the Game interface.

Argue whether the Game interface is a FACADE pattern or not. Argue for benefits and liabilities of this design.

Observer

Review the description of the observer system in HotStone in FRS 2nd Edition Section 37.6.1.

Use TDD to enhance your HotStone game system to notify observers of all relevant state changes.

Document your work ... as detailed in the Iteration 7 report template below.

As outlined in FRS Section 37.6, take care to avoid unnecessary observer updates: do not emit onPlayCard() events if the card was not played due to the hero having too little mana left, etc.

You will find the GameObserver interface in: GameObserver.java, and the Observable interface in Observable.java. It is important that you respect the package structure to prepare for the user interface exercises later.

You can of course code all the notification algorithms in your game implementation, but that is not the Compositional way. Use a delegate instead. I have coded a ObserverHandler.java which can lessen your work effort a bit.

Hint: You need a specific type of test double to solve this exercise. Which one?

Optional: Were they really Strategies?

Your HotStone system evolved into supporting BetaStone, GammaStone, ect., by using the 3-1-2 process/compositional design to introduce Strategies. Or... Were they really Strategy patterns after all?

Analyze each of your compositional designs/developed strategies carefully and determine if they are really a Strategy or actually some other design pattern, like Command, Abstract Factory, or ?

Transcript

Review the description of transcripting in HotStone in FRS 2nd Edition Section 37.6.2.

Enhance your HotStone game system with transcripting.

  1. Find a suitable design pattern to implement this requirement so any HotStone variant can be transcribed. Your implementation must be purely change by addition, not by modification. Specifically it is required not to use your Observer pattern.
  2. Implement your design and outline code fragments as illustration. Explain how you can turn transcribing on and off during the game.

... as detailed in the Iteration 7 report template below.

Notes:In this exercise, it is allowed to demonstrate that your transcript is working using manual tests, that is, just print the transcript using "System.out". This will lower your workload, compared to using a Test Spy.

WizardHub Effect Library

Refactor (parts of) your EtaStone card effects to use the WizardHub effect library as outlined in FRS §37.6.3, by implementing an Adapter for your MutableGame private interface.

  1. Sketch an UML for your adapter design.
  2. Refactor (parts of) your EtaStone card effects using WizardHub.
  3. Outline the Adapter code.

... as detailed in the Iteration 7 report template below.

Read the hint below to get the library into your IntelliJ/Gradle project.

Role diagram

Draw a role diagram (see Chapter 18) showing the part of the HotStone design that handles finding a winner of the game. The diagram must include all winner variants.

... as detailed in the Iteration 7 report template below.

Optional: Concept relations

Relate your design to the concepts of behavior, responsibility, role, and protocol. Find examples of abstractions, objects, and interactions in your HotStone system that are covered by each of the concepts above.

Deliveries:

  1. Develop on a feature branch named "iteration7" and release using a merge.
  2. Documentation for your work by following the requirements defined in the iteration 7 report template (pdf) (LaTeX source)

Notes and Hints

Gradle dependency for WizardHub library

To make your project's build.gradle use WizardHub library you need to do this:
  1. Include a dependency to 'wizardhub' version 1.0.0:
    dependencies {
      [your existing dependencies here]              
      // Maven Central dependency on WizardHub
      implementation group: 'com.baerbak.maven',
                name: 'wizardhub', version: '1.0.0'
    }
                
  2. If you edit your build.gradle in IntelliJ, you need to tell IntelliJ to 'reload the build script' using the 'elephant' button that appears in the top-right corner of the window.
    Now, the library is available in your project, and you can use name completion, etc.
  3. If IntelliJ chokes completely and does not understand that it is a Java/Gradle project (as I experience sometimes), try to 'Invalidate caches...' (in the File menu) in IntelliJ, or 'rebooting' the project as outlined in my IntelliJ tutorial (Section "Panic Button").

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.

Learning Goal Assessment parameters
Submission Git repository contains an "iteration7" branch that is merged into main/master branch. Git repository is not public! Required artifacts (report following the template) are present.
EC of attack() 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.
Observer The implementation of Observer is correct. The test cases are correct.
Facade + Role diagram The argumentation for Facade is correct and comprehensive. The role diagram is correct and argumentation is correct.
Transcript A correct design pattern is selected, the argumentation for choosing it is correct, and it is correctly implemented.
Adapter The UML diagram is correct, and proper code examples and argumentation are presented.