Mock driven development using .NET

Mock driven development using .NET

• 1.
  Mock driven development(with .NET) Test Driven Development with Mocks for .NET Framework By Punit Ganshani
• 2.
  Twitter - @ganshani @codetails LinkedIn - Connect Blog Sites – www.ganshani.com www.codetails.com Open Source – CodeInject, Workflow Extractor, dI.Hook Punit Ganshani Punit Ganshani is a Technology Evangelist practising application design & development on C#, WCF, WP8, WinRT and Open Source. He is an open-source contributor on CodePlex, has several applications on Windows Phone Store, author of a book, and 18+ whitepapers in international magazines.
• 3.
  Not in scope… AGILE MANIFESTO SCRUM KANBAN TFD vs. TAD
• 4.
  Test Driven Development(in a nutshell) A methodology that states that test cases should be driving the design decisions and development advocates knowing the expected behaviour of our application (or a part of it), before we write the code enforces incremental design and allows us to write just enough code to pass our test Test first Development vs Test after development Doing TDD well
• 6.
  Mock? Simulated objects thatmimic the behavior of real objects in controlled ways -Wikipedia Mock – to deceive, delude, or disappoint. - English Definition
• 7.
  The terminology Mocks, Stubs,… ▪ Mocks - Mock objects are used to define expectations i.e: In this scenario I expect method A() to be called with such and such parameters. Mocks record and verify such expectations.. ▪ Stubs - Stubs, on the other hand have a different purpose: they do not record or verify expectations, but rather allow us to “replace” the behaviour, state of the “fake”object in order to utilize a test scenario. ▪ Dummy - objects are passed around but never actually used. Usually they are just used to fill parameter lists. Source: http://martinfowler.com/articles/mocksArentStubs.html
• 8.
  Why mock? • Actualclass does not exist - Multiple development streams focusing on different components • Trips to external services, databases take a lot of time to execute • Non-existent or un-available dependent environments • A lot of UI input required in real-code • Abnormal, Unexpected conditions – outages, natural calamities, etc • Isolate code under test and narrow the scope
• 9.
  When to mock? ▪Unit Tests ▪ Mock the availability of ▪ external components ▪ non-existent classes ▪ services ▪ database calls ▪ Isolate the code under test and make it less fragile ▪ Integration Tests ▪ Do not mock your dependencies, service calls, database calls, etc ▪ Focus on checking the integration of all components ▪ Should not have any business-specific code
• 10.
  Types of mocks? ▪Strict ▪ Creates brittle tests ▪ Throws an exception if you try to use any method that has not explicitly been set up to be used. ▪ Normal, Loose ▪ Does not throw an exception if you try to use a method that is not set up, it will simply return a default value from the method and keep going.
• 11.
  How to mock– Existing Applications? Single Responsibility Principle (SRP) - an object should have only a 1 S single responsibility Open/Closed Principle (OCP) - open for extension, but closed for O modification Liskov Substitution Principle (LSP) - derived class should not break L assumptions or behavior of base class Interface Segregation Principle (ISP) - many specific interfaces are 2 I better than one general purpose interface (e.g. role interface) Dependency Inversion Principle (DIP) - depend upon abstractions, not 3 D upon concretions Source: http://prasadhonrao.com/tag/solid/
• 12.
  The steps ofmocking Arrange Act Assert • Data setup • Mock setup Execute the Verify the unit test output
• 13.
  Arrange : Object& Property Mocks RhinoMocks Moq NSubstitute
• 14.
  Arrange : MethodMocks RhinoMocks Moq NSubstitute
• 15.
  Arrange: Event Mocks RhinoMocks NSubstitute
• 16.
  Beware! ▪Remember what is mocked in which test – structure your unit tests appropriately ▪ Apply mocks only on Unit Tests, not integration tests ▪ Forces IoC container based design in and outside tests ▪ Dependencies (interfaces for mocks) should not have constructors ▪ GUI’s can’t be mocked, business logic should be Hybrid approach can be followed – Mock some things that are time consuming, external to your system, unreliable, not easily reachable and use real instances of others
• 18.
  Further Read ▪ UnderstandingMock and frameworks – Part 1 of N – Understanding the need of TDD, Mock and getting your application Unit Test ready ▪ Understanding Mock and frameworks – Part 2 of N – Understanding Mock Stages & Frameworks – Rhino Mocks, NSubstitute and Moq ▪ Understanding Mock and frameworks – Part 3 of N - Understanding how to Mock Methods calls and their Output – Rhino Mocks, NSubstitute and Moq ▪ Understanding Mock and frameworks – Part 4 of N - Understanding how to Mock Exceptions and Event Subscriptions – Rhino Mocks, NSubstitute and Moq