Mock driven development using .NET


Published on

Mock driven development using .NET frameworks like Rhino Mocks, Moq, NSubstitute

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Mock driven development using .NET

  1. 1. Mock driven development (with .NET)Test Driven Development with Mocks for .NET FrameworkBy Punit Ganshani
  2. 2. Twitter - @ganshani @codetails LinkedIn - Connect Blog Sites – Open Source – CodeInject, Workflow Extractor, dI.HookPunit GanshaniPunit 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 applicationson Windows Phone Store, author of a book, and 18+ whitepapers in international magazines.
  4. 4. Test Driven Development (in a nutshell)A methodology that states thattest cases should be driving the design decisionsand developmentadvocates knowing the expected behaviour of our application (or apart of it), before we write the codeenforces incremental design and allows us to write just enough codeto pass our test Test first Development vs Test after development Doing TDD well
  5. 5. Mock?Simulated objects that mimic the behavior of realobjects in controlled ways -WikipediaMock – to deceive, delude, or disappoint. - English Definition
  6. 6. The terminologyMocks, 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:
  7. 7. Why mock?• Actual class 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
  8. 8. 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
  9. 9. 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.
  10. 10. How to mock – Existing Applications? Single Responsibility Principle (SRP) - an object should have only a1 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 are2 I better than one general purpose interface (e.g. role interface) Dependency Inversion Principle (DIP) - depend upon abstractions, not3 D upon concretions Source:
  11. 11. The steps of mocking Arrange Act Assert• Data setup• Mock setup Execute the Verify the unit test output
  12. 12. Arrange : Object & Property MocksRhinoMocks Moq NSubstitute
  13. 13. Arrange : Method MocksRhinoMocks Moq NSubstitute
  14. 14. Arrange: Event MocksRhinoMocks NSubstitute
  15. 15. 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 beHybrid approach can be followed – Mock some things that are time consuming,external to your system, unreliable, not easily reachable and use real instances ofothers
  16. 16. Further Read▪ Understanding Mock 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