More Related Content


Battle of The Mocking Frameworks

  1. Dror Helper | @dhelper | Battle of the Mocking Frameworks
  2. • Consultant @CodeValue • Developing software (professionally) since 2002 • Disclaimer: I used to work @Typemock • Blogger: About.ME
  3. This is unit testa [Test] public void AddTest() { var cut = new Calculator(); var result = cut.Add(2, 3); Assert.AreEqual(5, result); }
  4. Real code has dependencies Unit test Code under test Dependency Dependency
  5. The solution - Mocking Unit test Code under test DependencyFake object(s)
  6. • Replace production logic with custom logic • We do this in order to – Focus the test on one class only – Test Interaction – Simplify Unit test writing Isolation
  7. What is a “Mock”? “mock objects are simulated objects that mimic the behavior of real objects in controlled ways” [From Wikipedia] I prefer to call them “Fakes”
  8. Manual/Hand-rolled mock • Use inheritance to replace production logic. • Use configurable delegates as custom logic. PasswordChecker PasswordChecker(IDataAccess) CheckPassword(string, string) DataAccess GetUserByName(string) SaveUser(string, string)
  9. The problem • Maintainability – it’s a lot of work • Gets complicated as more functionality is required: • Production logic inside fakes • Error prone - how do we avoid bugs in test?
  10. • Create Fake objects • Set behavior on fake objects • Verify method was called • And more... What Mocking framework can do for you?
  11. Meanwhile in the .NET world Open source • FakeItEasy • Moq • NMock3 • nSubtitute • Rhino Mocks Free • MS Fakes Commercial • Isolator • JustMock
  12. Usage statistics (2012) Moq 45% Rhino Mocks 23% None 9% FakeItEasy 6% Nsubstitute 6% Isolator 4% Moles 2% MS Fakes 2% JustMocks 2% Other 1%
  13. • Married into your (test) code • Saves/waste development time • Affects design Choosing the right framework is crucial
  14. Round 1 - API
  15. Mock-Demo DB Read Data Request Response
  16. API summary Error msgParametersBuilderSPEReadability +ExplicitYesNo+Moq -ExplicitNoNo+Rhino-Mocks +ExplicitNoYes+FakeItEasy +ExplicitNoNo+nSubtitute ?ExplicitYesNo-NMock3 +ImplicitNoYes+Isolator -ExplicitNoYes+JustMock N/AExplicitYesNo-MS Fakes Error msgParametersBuilderSPEReadability +ExplicitYesNo+Moq -ExplicitNoNo+Rhino-Mocks +ExplicitNoYes+FakeItEasy +ExplicitNoNo+nSubtitute ?ExplicitYesNo-NMock3 +ImplicitNoYes+Isolator -ExplicitNoYes+JustMock N/AExplicitYesNo-MS Fakes
  17. Round 2 - Robustness Code under test API changes • Method signature • Method name Code under test internal changes • Unexpected call to fake • Return value from unspecified method Future proof
  18. Round 3 Unconstrained
  19. Constrained • Fake by inheritance • Force architecture – Dependency injection (DI) – Code by interfaces (LSP) • Wrapping of the unfakeable Real object Fake object
  20. Unconstrained • Profiler API based • Can fake almost anything – 3rd party systems – Legacy code • Design your code - not for testability • Can be used as if they are constrained Real Object Dependency Fake
  21. Constraint •NMock3 •FakeItEasy •nSubtitute •Moq •RhinoMocks Unconstraint •Isolator •JustMock •MS Fakes
  22. Nickels and dimes Constraint frameworks are free – but can you afford them? How much does it cost if every task takes 1 hour more? How much does it cost not to use unit tests?
  23. Round 4 - deployment
  24. Deployment – the bottom line MS FakesJustMockIsolatorConstraint Visual studio 2012/2013 Install on each machine. Install on each machine. Auto-run correct version Nothing (NuGet) Dev machine Only TFS (> 2012)Install on each machine. Install or use AutoDeploy NothingBuild Server Only TFS (> 2012)Environment vars JustMockRunner Build Tasks Environment vars TMockRunner Build Tasks Just run itRun tests on build machine Only VS profilersUse LinkerAutomatic LinkerWorks!Profilers Support
  25. Which framework is better?
  26. Dror Helper C: 972.05.7668543 e: B: w:

Editor's Notes

  1. Maintainability – it’s a lot of work Gets complicated as more functionality is required: Setting different behaviors Multiple parameters Checking for multiple calls Production logic inside fakes What happens when our code changes? Error prone - how do we avoid bugs in test?
  2. Possible changes: CUT adds/remove a parameter Dependency API change Add call to the same dependency without specifying in test Change to another overload of the same function