SWEA 2025 Weekplan 8

The learning goals for Week 43 are:

Mon: (Week 43 at 8.15) Systematic Testing: Equivalence Class Partitioning. Wed: Code Coverage.

Literature:

Slides:

Notes for this weekplan:

The big topic this week is systematic testing and I need the full two hour slot. So Monday lecture starts at 8.15. The Wednesday lecture will be about code coverage, explaining in further detail what those red/yellow/green colors of the JaCoCo output really is.

There is no delivery of mandatory this week. You should spend time on the Adapter kata below (preparing you for an Iteration 7 mandatory exercise) and otherwise spend the time in the Lab on rehearsing the exam situation using the demo-question-2025.pdf. Finally, you may of course begin to look at the Iteration 7 mandatory...

Kata

Spend the first 15-20 minutes of the TØ/Lab class in plenum discussing...

... Adapter pattern for the WizardHub library

Review FRS §37.6.3 for an introduction to WizardHub: a library to write hero powers and card effects in a concise manner. Iteration 7 mandatory will ask you to introduce this into your HotStone game.

As WizardHub is an open-source library, it can of course not call methods in your group's particular HotStone game implementation directly. The solution is the Adapter pattern.

Review the UML diagram for the Adapter pattern (Design pattern box [21.1] in FRS) (reproduced below).

Discuss...

  1. Draw an UML diagram that mimics the Adapter one above, but with the concrete interfaces/classes from your particular hotstone design and the WizardHub interfaces/classes in their right roles. Hint: the EffectWizard class is the Client role. Add your MutableGame private interface and the HotStoneGameTarget interface in the diagram.
  2. How would Thai Chef's hero power 'Chili' (reduce health of opponent's hero by 2) look like when coded using the WizardHub library?
  3. Review the source code for the HotStoneGameTarget interface and outline which of the HotStoneGameTarget's methods would the above 'Chili' implementation call? (Note: there are actually two calls.)
  4. How will you adapt these to call your own Game's private interface?
  5. Sketch a plausible constructor of your own implementation of the HotStoneGameTarget.
  6. Consider the invalid call 
    new EffectWizard(game)
  .forMe().forMinionAt(10)
  .doChangeAttack(+1);
    on a game with only three fielded mininons. What would be a proper design, according to one of Uncle Bob's clean code properties?
  7. Optionally, download the library (or study the test code on BitBucket) to see what happens in case an invalid EffectWizard object is executed.

Optional Exercises:

These are optional exercises. Be sure to solve the mandatory project first, and only if you have a lot of spare time, try having a look at the exercises below.

Exam Rehearsal

Rehearse a systematic testing exam situation. Spend 20-25 minutes to prepare a 10 minute oral presentation of an exercise in the example exam question set: demo-question-2025.pdf.

Next, do a 10 minute presentation at the whiteboard in front of your team.

The team provides constructive feedback on the presentation: Is your presentation clear and understandable, do you discuss the concepts and terms correctly, is you Java example code correct, etc. Swap and ensure all in the team gets a chance to rehearse the situation.

FRS exercises

25.2 (Proxy) 34.3 (EC on Breakthrough game (described in exercise 5.4))

Null Objects

The Null Object pattern is a much safer way to encode 'no behavior' than using null pointers.

Review your HotStone code base for delegates that implement the Null Object pattern. There should be plenty!

Strengthen analyzability of your HotStone codebase by refactoring/renaming those delegates to indicate that they are indeed nullobjects.