1. DAIMIHenrik Bærbak Christensen1 Mandatory Project Part II Software Reliability and Testing

2. DAIMIHenrik Bærbak Christensen2 Aim To use techniques from the course to –plan and perform integration testing of your own module (or ‘cluster’) at least three other modules Game: a top-level user interface module

3. DAIMIHenrik Bærbak Christensen3 Entailing You must report –“topological sort” – dependency analysis of clusters/classes –test plan: order of integration and rationale integration strategy developed stubs and drivers –report integration defects and probably fix some of them in order to progress...

4. DAIMIHenrik Bærbak Christensen4 Top level TestGame –“test” tree, package sratworld.textui –uses stubs for all modules Example of –Top-Level integration step 1 –TDD of top level implementation

5. DAIMIHenrik Bærbak Christensen5 Design overview Game: Responsibilities –text-based “read-interpret-execute” command loop ‘loop’ method –visual overview of area, actors, and items –configurable to specific game context Loaders + config file location in constructor register Event instances and bind them to command characters

6. DAIMIHenrik Bærbak Christensen6 Example: TestGame

7. DAIMIHenrik Bærbak Christensen7 Stubbing as an art-form Top-level integration require stubs to verify behaviour of top level unit Game require: –Loaders: to create the object set: area, actors, items... –Events: to demonstrate binding between command interpretation and execution Everything is stubbed in TestGame

8. DAIMIHenrik Bærbak Christensen8 Stub Loaders

9. DAIMIHenrik Bærbak Christensen9 Stub Events g.registerEvent(new InventoryEvent(),’i’); Local Event implementation form a stub:

10. DAIMIHenrik Bærbak Christensen10 (Stub) Listener Updating the visual display –Base level is too ‘base’ at the moment no notion of ‘hero’ nor ‘hero position’ –thus: no way for base layer to update any graphical viewer

11. DAIMIHenrik Bærbak Christensen11 The viewer The viewer is a high performance 3D real-time high-resolution graphics engine –... in the next release Until then, the old MiniDraw workhorse draws some crude graphics –load GIF files (32x32 pixel) in specific positions –iterate tiles in Area instance and draws them... Keep out of there, and report defects to me...

12. DAIMIHenrik Bærbak Christensen12 Back to the exercise...

13. DAIMIHenrik Bærbak Christensen13 Modules/Clusters Make dependency graph for selected clusters –Game –Loaders –Listeners –Meta Events –Module classes any you have made –Base classes Base classes I’ve made Game Loader Event Mod Cl. Event Base Cl. Event Listeners

14. DAIMIHenrik Bærbak Christensen14 Integration steps Both Burnstein and Binder advocate step-wise integration –integrate one cluster, A, at a time identify test cases for integrating A use them to integrate A and find defects –repeat until no more clusters to integrate

15. DAIMIHenrik Bærbak Christensen15 TD versus BU Our hierarchy is pretty shallow, so what does TD versus BU mean? Example: If you were responsible for Area module TD: –step 1: replace AreaLoader stub with our group’s AreaLoader –testcase: manual test case: Run TestGame01 and visually inspect that a) geography corresponds to what is read from config file BU –step 1: Integrate Actor I module with our group’s area module –testcase: JUnit: Hero is in proper location in proper area

16. DAIMIHenrik Bærbak Christensen16 Reporting JUnit test case overview –purpose – refer to real JUnit test cases Manual test cases –described well enough to be repeatable Learning focus: –Demonstrate that you can do it! not that you can do it 2000 times

17. DAIMIHenrik Bærbak Christensen17 Exercise Release Exercise will be finally released wednesday I will include a small exercise relating to system testing – use case coverage?