1 / 20

Using Mock Objects with Test Driven Development

Learn about utilizing mock objects in test-driven development to isolate code, verify interactions, handle abnormal situations, and improve software testing. Discover the benefits, pitfalls, and design considerations when using mock objects.

judithrwilliams
Télécharger la présentation

Using Mock Objects with Test Driven Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Using Mock Objects withTest Driven Development Justin Kohlhepp jkohlhepp@gmail.com

  2. What are mock objects? From Wikipedia: simulated objects that mimic the behavior of real objects in controlled ways Think “crash test dummy”

  3. TerminologyMocks, Stubs, Fakes… Whatever!

  4. TerminologyUnit Tests vs. Integration Tests

  5. Why use mocks? • Isolate code under test; less fragile tests • Difficult to set up dependencies • Verify interaction between objects • Side effects (sending emails, launching missiles) • Abnormal situations (network outages, disk full) • Multiple dev streams (actual class doesn’t exist) • Non-deterministic results (timezones) • Real code too slow (trips to database) • Real code interacts with user (i.e. UI) 

  6. Demo Simple Mocking Scenario

  7. moq Basic Syntax http://code.google.com/p/moq/wiki/QuickStart

  8. moq Framework http://code.google.com/p/moq/ • Pronounced "Mock-you" or just "Mock“ • .NET 3.5 or higher • Focused on simple, flexible API • Does not use record/replay style • Open source, BSD license • Active project since 2007

  9. Test Lifecycle with Mocks

  10. Demo: Advanced moq Features • Mocking Exceptions • Loose vs. Strict • Complex argument matching • Callbacks • Mock concrete classes, Partial Mocks • Automatic recursive mocks • Mock multiple interfaces  • Access to protected members

  11. Design Considerations – “SOLID”

  12. Managing Dependencies • “new” keyword prevents isolation • Inversion of Control: class no longer controls its dependencies; no more “new” • Key patterns for IoC: Dependency Injection, Service Locator

  13. Demo Dependency Injection

  14. Dependency Injection Frameworks • Allow for externalizing dependency management • Can be configuration driven or code driven • Many choices: MS Unity, Castle Windsor, StructureMap, Ninject, etc.

  15. Demo “Realistic” Mocking Scenario

  16. moq – Under the Hood • Uses Castle DynamicProxy • Creates class on the fly that implements interface or derives from class • Tracks methods, properties that are setup on the mock, and how they are invoked during test execution

  17. Other Mocking Frameworks

  18. Mocking Pitfalls • Gaps in integration testing • Maintenance concerns • Testing influencing design  • Tests are very “white box” – they know a lot about the thing they are testing • To verify or not to verify • Heisenbugs • Controversy

  19. Conclusions • Mock objects are a powerful tool that you should have in your testing toolbox • Injecting mock objects requires some design considerations. Luckily this also leads to better code (according to some). • Remember: a hybrid approach is possible. Mock some things and use real instances of others. • With great power comes great responsibility

  20. Useful Links • Wikipedia: Mock Objectshttp://bit.ly/7WWq9 • Fowler: Mocks Aren’t Stubshttp://bit.ly/7MdzF • QuickStart with moqhttp://bit.ly/13FYvA • Working Effectively with Legacy Codeby Michael Feathershttp://amzn.to/Mf59m

More Related