Type mock isolator
Upcoming SlideShare
Loading in...5
×
 

Type mock isolator

on

  • 818 views

 

Statistics

Views

Total Views
818
Views on SlideShare
818
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Reference: http://weblogs.asp.net/rosherove/archive/2007/04/26/choosing-a-mock-object-framework.aspxNmock: http://www.nmock.org/cheatsheet.html

Type mock isolator Type mock isolator Presentation Transcript

  • TypeMock Isolator Mocks/Fakes/Stubs By Brandon D’ImperioImaginaryDevelopment@gmail.com
  • Testing is hard!• Testing is too much work• I can’t get my developers to write tests• I can’t get my teammates to write tests• My codebase was not written with testability• Mocking frameworks take too much work to fake out deep call chains• My dependencies are static, sealed, or non- public and can’t be faked
  • Jargon/Definitions• Unit Test – Code (usually a method) that runs another piece of code (usually a single method/function in isolation) and checks the correctness of an assumption afterward. If the assumptions are wrong, the unit test is failed.• Fake – Encapsulates noth Stubs and Mocks• Stub – A controllable replacement for an existing dependency in the system. – Use a stub to test your code without dealing with the dependency directly – Can not fail a test – Usually just a dummy object that does nothing, returns property values as instructed – Not the item being tested again• Mock – A fake object in the system that decides whether the unit test has passed or failed. – Does so by verifying whether the object under test interacted as expected with the Fake
  • Testing Types
  • Testing• User Model Testing - link• Acceptance Testing - link• Usability Testing• Performance and load testing• Security Testing• Integration Testing• Unit Testing – uses fakes to isolate
  • Unit Testing weaknesses• Can not catch integration errors, system-level errors, or non-functional (performance, security, etc)• Additional maintenance• Additional coding• Unit tests may share the same blind spots as the code because they are written by the same developer
  • Unit Testing strengths• A code driven documentation – Less likely to get out of sync than comments – Less likely to get out of sync than documentation• Regression reduction• Instant feedback• Safer refactoring and feature addition• Unit tests may help the developer find blind spots
  • What is a good unit test?• Automated/repeatable• Easy to implement• Once written, remains for future use/versions• Anyone should be able to run it• Runs quickly (up to 20,000 in a minute) – No dependencies
  • What’s a mock/isolation framework?• In order to properly unit test your external dependencies must be replaced. A unit test should ONLY fail because of the code you are testing, otherwise it’s an integration test.• A mock framework is a tool to replace external dependencies with fakes.
  • What does TypeMock bring?• Fake static/sealed/non-public elements – DateTime.Now faking!• No design for testability required• Recursive fakes (nested call chains) a.b.c.d
  • Code!• Let’s look at some actual code
  • TypeMock vs Others• Some mock frameworks can only mock interfaces• nUnit.Mocks – no events or generics mocking• Rhino Mocks – no strings for method names, single developer (if he stops, game over?) – Documentation does not appear to support non- interface mocking• nMock 2.0 – currently in RC status, appears to require interfaces to fake
  • Debate• Advocates of Testability say you don’t get the clean SOLID design of writing for testability• Should the isolation framework be dictating design decisions?• Design for testability leaves out the majority of work… Brownfield applications
  • TDD and indirectly unit testing research• "We found that test-first students on average wrote more tests and, in turn, students who wrote more tests tended to be more productive. We also observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed."• "The external validity of the results could be limited since the subjects were students. Runeson [21] compared freshmen, graduate, and professional developers and concluded that similar improvement trends persisted among the three groups. Replicated experiments by Porter and Votta [22] and Höst et al. [23] suggest that students may provide an adequate model of the professional population."• Taken from http://weblogs.asp.net/rosherove/archive/2008/01/25/research- finds-tdd-boosts-developer-productivity.aspx
  • More reading…• Martin Fowler – Mocks aren’t stubs• Uncle Bob – TDD Derangement Syndrome
  • Good Practices• Only a single Assert per test• Code a test for both the Happy Path and the Unhappy Path• Start out testing by hitting your longest, most cyclomatically complex, most critical, or just hardest to understand methods.• Try to reduce the external dependency contact points in a class• Write a test that FAILS first! Write the test before the code, or comment out the part that should make it succeed.
  • My Passions• Tooling anything that makes coding easier or more productive• MVC• Extensibility