Iteration 7: Blackbox Testing and Pattern Hunting

Deadline

Always at 23.59 on the same day as your TA session (Except if another deadline has been agreed with the TA). 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 HotStone design.

Kata

Spend the first 15-20 minutes of the class in plenum discussing...

... the HotStone observer protocol

The learning goal of this kata is to explore the new role that Game must support: to be Observable; and thus help you in solving the 'Observer' exercise below.

Study FRS § 37.6 carefully, as it outlines the protocol to use in our HotStone system. You will find the full GameObserver interface in: GameObserver.java, and the Observable interface in Observable.java.

Consider the following scenarios during a HotStone game, and sketch the expected call sequence of onX() that will arrive at the Observer of the game (no coding, just draw a sequence diagram or list the onX() calls as shown below):

  1. Findus uses the power of ThaiChef (power: reduce opponent Hero by 2 health) and has enough mana to do so. (This is the FRS §37.6 example)
    Solution:
    onUsePower(FINDUS) - due to the mutator being called
      onHeroUpdate(FINDUS) - due to hero spending mana
      onHeroUpdate(PEDDERSEN) - due to opponent health reduced
                
  2. Findus tries to use the power of ThaiChef but only has one mana.
  3. Peddersen successfully plays "Spring Rolls" from EtaStone (Destory a random opponent minion) which kills Findus' "Brown Rice" minion.
  4. Peddersen successfully plays "Noodle Soup" from EtaStone (Draw a card from deck).
  5. Peddersen ends his turn [Consider both that Findus' deck is exhausted or it is not].
  6. Findus successfully plays "Holy Nova" from "FutureStone" (Deal 2 damage to all enemy minions. Restore 2 Health to all friendly characters.). Findus has Brown Rice and Poke Bowl fielded, while Peddersen has Spring Rolls (health 4) and French Fries (health 1) fielded.

Furthermore, discuss the distinction between 'Direct' and 'Indirect/derived' events in the GameObserver interface. What reasons can there be for including the 'Direct' onX() calls?

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.

  1. Describe a list of the relevant conditions that influence function 'attack()'.
  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.

Note: You should not implement RhoStone. This is a purely theoretical exercise.

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.

Find details in the report template about how to document your work.

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.

Find details in the report template about how to document your work.

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.

Find details in the report template about how to document your work.

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.

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 request.
  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 '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 merge request associated with "iteration7". 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.