Mandatory 3 Test Stubs State Abstract Factory

Stubs, Spies, and Fake Objects One Example Making distribution testable... Henrik Bærbak Christensen2

Ecosense Karibu framework Henrik Bærbak Christensen3 RabbitMQ Mirrored Cluster MongoDB ReplicaSet / 3 Instances

Stubs – allow us to test! Henrik Bærbak Christensen4

Happy path test Henrik Bærbak Christensen5 Send the objects Validate they are stored in the DB

... on test doubles... Henrik Bærbak Christensen6

... And simulate failure situations Henrik Bærbak Christensen7

Back to HotCiv EpsilonCiv needs a die roll –Question: How do we make automatic tests with a random die? –Answer: We do not! Analysis –The random generator in the system libraries is indirect input which must be put under testing control... Henrik Bærbak Christensen8

Also... The context of the test is difficult! What is easier and more specific to test? –O –A x d1and D x d2 Henrik Bærbak Christensen9

Which one is the Test Stub? Henrik Bærbak Christensen10

This is not Abstract Factory! Henrik Bærbak Christensen11

This is not Abstract Factory! Henrik Bærbak Christensen12 Question: How to reconfigure at run-time? What if Game needed to produce ‘product’s later (like Receipts in PayStation?) A very common trap! But it is not an Abstract Factory! Code like this – put it in the main() method

AbsFactory – UML clutter... Henrik Bærbak Christensen13

Abstract Factory Hierarchy Question: –Interface: CivFactory –Subclass: AlphaFactory implements CivFactory –??: BetaFactory extends AlphaFactory Fine – Beta IS-A Alpha with some changes, so the subclass hierarchy works out OK – but naming bad! > Figure – > AbstractFigure –RectangleFigure, CircleFigure, LineFigure,... Extend AbstractFigure Henrik Bærbak Christensen14

Abstraction and parameterization When we introduce Green and Yellow player? Henrik Bærbak Christensen15

Remember: Refactor Henrik Bærbak Christensen16 Use the flat ‘fail-fast’ strategy

Appears General – but is not Henrik Bærbak Christensen17

State – and annoying state! Who stores what? Attacks won by player Henrik Bærbak Christensen18

Problem statement When doing compositional designs we –Cut behaviour that is often otherwise in the same abstraction, and therefore have access to the same state (i.e. The same set of instance variables)... Parametric: all in the same class Polymorphic: subclasses still contain all of superclass var. –... Into multiple objects But how do they share/exchange state!!! Henrik Bærbak Christensen19

Example WinnerStrategy: Algorithm to determine winner Based upon knowledge of –Alpha: The age (correlates to rounds) –Beta: Owner of all cities –Epsilon:3 attacks won by player –Zeta:Rounds+Beta+Epsilon’ Epsilon’ = counting won attacks only starts after 20 rounds But who is responsible for ”knowing it”? Henrik Bærbak Christensen20

Example Who should know it? –Game or the WinnerStrategy or some third object? –Game/WinnerS: Number of rounds played/age –Game: Owner of all cities –WinnerS:Attacks won by player –WinnerS:Counting only starts after 20 rounds Known by Game Not really known by the Game Henrik Bærbak Christensen21

Discussion A key point here is –There is no single best answer here! Game and strategies have to collaborate rather closely in order to provide the required behaviour So – evaluate cohesion and divide responsibilities consistently, and define the protocol that allows them to exchange state changes properly –And argue for it... Henrik Bærbak Christensen22