Iteration 7: Blackbox Testing and Pattern Hunting

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 "Chicken Curry" from EtaStone (Kill random opponent minion) which kills Findus' "Pumpkin soup" minion.
  4. Peddersen successfully plays "Noodle Soup" from EtaStone (Draw a card from deck).
  5. Peddersen ends his turn.
  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 onCardPlay() 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.

Personalized Decks

Implement the Personalized Decks requirement (FRS 37.6.3) by finding a suitable design pattern allowing to change by addition, not by modification of your HotStone system.

  1. Find a suitable pattern to implement this requirement.
  2. Implement your design and outline code fragments as illustration.

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

The external deck library is demonstrated in the following gradle project: demo-deck.zip. Unzip it and follow the instructions in the ReadMe.md file. To include the library in your own HotStone, you need to update the build.gradle file, see Note 1 below.

Notes: To make the exercise easier, you are not required to shuffle the deck.

Disclaimer: The personal decks cannot be used with the graphical user interface as there are no images that match the cards.

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.

Optional: Effects using a Bloch Builder

Heartstone's card library lists more than 1,000 cards, most of them having all kinds of effects. To code all these effects, an analyzable way for writing (many) effects is essential.

A Bloch builder/fluent API is one such analyzable technique to do so. I have written a builder object, Effect, with setter methods and a set of finalizing execution methods. This allows me to write Tomato Salad (add +1 attack to random own minion) like this:

  new Effect(mutableGame)
    .forMe()
    .forRandomMinion()
    .deltaAttack(+1)
        
and Chicken Curry (remove random opponent minion) like this:
  new Effect(mutableGame)
    .forOpponent()
    .forRandomMinion()
    .removeMinion()
        
and Holy Nova of Hearthstone (heal all my minions by 2; deal 2 damage to all opponent minions) as:
  new Effect(mutableGame)
    .forOpponent()
    .forAll()
    .deltaHealthOrRemove(-2);
  new Effect(mutableGame)
    .forMe()
    .forAll()
    .deltaHealthOrRemove(+2);
        
(mutableGame is my private interface holding the mutator methods of Game).

Refactor your hero powers and card effects to use a fluent API for effects.

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

Note 1: Gradle dependency for Personal Deck library

To make your project's build.gradle use the personal deck builder library you need to do this:
  1. Update the repository section to include SonaTypes snapshot repository:
    // The deck building library is not an official library, so I have put it
    // in a SNAPSHOT repository that needs the full URL to pull.
    repositories {
      maven {
        url "https://s01.oss.sonatype.org/content/repositories/snapshots/"
      }
      mavenCentral()
    }
                
  2. Include a dependency to 'hotstone-deck' version 1.0-SNAPSHOT:
    dependencies {
      [your existing dependencies here]              
      implementation 'com.baerbak.maven:hotstone-deck:1.0-SNAPSHOT'
    }
                
  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").

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 + Personalized Decks Correct design patterns are selected, the argumentation for choosing them is correct, and they are correctly implemented.