testing with mock objects

when i say testing…

== developer / unit tests

== integration tests (sometimes)

!= functional / acceptance tests

when i say mock…

test stub

mock object

dummy object

fake object

mock vs. stub interaction vs. state

the difference between mocks and stubs

usually the same library provides both

interaction = mock

state = stub

why?

testing is easy in isolation

Class Under Test

Test Class

testing is harder with dependencies …

Class Under Test

Test Class

… so remove the dependencies (for developer testing)

Class Under Test

Test Class

mock

mock

mockm

ock

for me…

lots of time in the airport

lots of time in the airplane

lots of time on the train

not enough family time

not enough snowboarding

scenarios to think about

fee per transaction

distributed development

parallel development

plug-ins / providers

automated test duration

scenarios to think about

third-party tools or services

non-deterministic outcomes

external systems

the mainframe crew

defer infrastructure choices

demo

thoughts

… on architecture and design

similar to the benefits of tdd

writing to interfaces = code empathy

easier to test = good design

highly cohesive / loosely coupled

… on implementation

good libraries exist

roll your own only for extreme cases

for .Net…

NMock, NMock2, Rhino Mocks, DotNetMock

… on automated builds

developer tests: use mocks (if necessary)

acceptance tests: don’t use mocks

… on a few useful patterns

code to interfaces

thin proxies

self-shunt

dependency injection

providers

learn more

http://www.martinfowler.com/articles/mocksArentStubs.html

http://xunitpatterns.com/

http://www.nmock.org

http://www.mockobjects.com

http://www.codeproject.com/dotnet/tdd_in_dotnet.asp