Punit Ganshani is a technology evangelist who practices application design and development using C#, WCF, WP8, and WinRT. He advocates for test-driven development and uses mocking to simulate objects and isolate code under test. Mocking frameworks like Rhino Mocks, Moq, and NSubstitute allow mocking method calls, properties, and events to set up test scenarios without dependencies. Unit tests should focus on mocking while integration tests rely on real dependencies.

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 that mimic 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?
• 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

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 of mocking
Arrange Act Assert
• Data setup
• Mock setup
Execute the Verify the
unit test output

13. Arrange : Object & Property Mocks
RhinoMocks Moq
NSubstitute

14. Arrange : Method Mocks
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
▪ 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