GMU SWE-795 Test Driven Development Seminar. Spring 2011. This is my initial contribution to the class.

1. Test Doubles Mock Objects & Design Principles SWE-795, Test Driven Development, GMU Spring 2011 – Bill Shelton

2. “Once”, the Mock Turtle said at last, with a deep sigh, “I was a real turtle.” Lewis Carroll, Alice’s Adventure in Wonderland

4. Dependency Example code: https://gist.github.com/840494

5. Ways to build Mocks Code by hand (Fakes) Extend the depended-upon object and override methods Build lightweight representations; e.g., anonymous classes What does this smell like? On-the-fly with a mocking framework Lots to choose from Almost all have some limitations

6. State and Behavior Verification State-based tests assert the resultant state of an operation on the object under test Behavior-based tests verifyhow the object under test interacts with its collaborators Should these be considered mutually exclusive activities?

7. <code/> : https://gist.github.com/840494

8. Classicists and Mockists(Fowler) Coupling to Implementation: Classicists think it’s important to only think about the external interface, whereas Mockistsmust consider the implementation … What about considering various paths in state-based tests?Classicist do need to look beyond the interface. This is a design activity. Test Isolation: Fowler seems to imply that this is less important to state-based tests * Test Driven Design Idioms (Let’s see some case studies) Outside-in vs. Middle-out “Tell Don’t Ask” Law of Demeter, or nearest neighbor principle

9. Discovering New Types Freeman and Pryce describe Need-Driven Development as an outside-in approach Thinking in terms of layers, starting with the outside first, build inwards using Mock Objects to discover interface needs An interesting Agile idea, but in practice how does it work? Case study? Process: Refer to earlier Dependency Slide Collaborators evolve and become SUT

10. Summary Mocks can be used for: Managing test-time dependencies (databases, network services, email, etc.) Verifying howthe object under test interacts with its collaborators Driving an outside-in design process Discovery of new types Other points Decouple dependencies in code to allow injection of mocks; e.g., setCollaborator(Collaborator c) Consider control and isloation

11. Other Applications for Mocks? It appears that Mocks have only been considered as an aid to testing, design, and TDD. If Mocks can simulate behavior, could they be used for other purposes? Software simulation Simulate faulty behavior or state … Mutant behavior Given a known behavior of the application of a specific mutant operator, could we simulate that using Mock Objects?

12. Some mocking frameworks Java jMock, EasyMock, PowerMock, jMockit, Mockito .NET NMock, moq, EasyMock.NET, Rhino Mocks Python Pymox, dingus ColdFusion MightyMock (part of MXUnit), MockBox, ColdMock, CFEasyMock Ruby rr, mocha, flexmock, stump, facon

13. Geeky Chuck Norris Jokes Chuck Norris can divide by Zero. Chuck Norris can count to infinity … twice! Chuck Norris doesn’t do TDD. Bugs are too damn scared to go anywhere near his code.

14. Complete Path Coverage CPC Prime Path Coverage PPC Edge-Pair Coverage EPC All-DU-Paths Coverage ADUP All-uses Coverage AUC All-defs Coverage ADC Edge Coverage EC Simple Round Trip Coverage SRTC Complete Round Trip Coverage CRTC Node Coverage NC Introduction to Software Testing (Ch 2) © Ammann & Offutt

15. Complete Path Coverage CPC Prime Path Coverage PPC Edge-Pair Coverage EPC All-DU-Paths Coverage ADUP All-uses Coverage AUC All-defs Coverage ADC Edge Coverage EC Simple Round Trip Coverage SRTC Complete Round Trip Coverage CRTC Node Coverage NC The Chuck Norris Criterion subsumes ALL other criteria. Period. The End. Chuck NorrisCoverageCNC Introduction to Software Testing (Ch 2) © Ammann & Offutt