1. Mandatory 3 Test Stubs State Abstract Factory

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

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

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

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

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

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

8. 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

9. 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

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

11. This is not Abstract Factory! Henrik Bærbak Christensen11

12. 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

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

14. 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

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

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

17. Appears General – but is not Henrik Bærbak Christensen17

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

19. 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

20. 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

21. 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

22. 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