The 7 Phases of Unit Testing

1 – Refuse to unit test because “you don’t have enough time”
2 – Start unit testing and immediately start blogging about unit testing and TDD and how great they are and how everyone should do it
3 – Unit test everything – make private methods internal and abuse the InternalsVisibleTo attribute. Test getters and setters or else you won’t get 100% code coverage
4 – Get fed with how brittle your unit tests are and start writing integration tests without realizing it.
5 – Discover a mocking framework and make heavy use of strict semantics
6 – Mock absolutely everything that can possibly be mocked
7 – Start writing effective unit tests

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

26 Responses to The 7 Phases of Unit Testing

  1. zhaorui says:

    Would you mind I translate this article to chineses?

    if you don’t like this, please tell me.

  2. My experiences/phases haven’t been like that at all. Mine were more like this:
    1. read a crap ton of TDD books
    2. read some more
    3. read kent becks and finally ‘get it’
    4. do it ALOT by myself
    5. blog about it alot because to teach is to learn
    6. pair program and try to explain it.
    7. try not writing any code without a test
    8. realize it’s not possible nor reasonable to test every single thing
    9. find balance and humility and the sweet spot for ROI in testing in cohesion with QA people.

  3. Brian says:

    @effective unit testing resource: The Art Of Unit Testing by Roy Osherove – practically free if you buy the e-version.

    @Chris: Typemock Isolator


  4. lpodolak says:

    8 – Discover BDD
    9 – there is no 9 .. for now.

  5. karl says:

    You shouldn’t make a private method internal or public just so that you can test it. The tests that you write which cover the real public methods should hit your private methods and cover them.

  6. jose says:

    What would be the most use pattern for testing settings the methods as public or setting them internal with internalsVisisbleTo?

  7. karl says:

    I’ll get back to this topic shortly (in a more serious way). I’ve blogged about effective unit testing in the past, but I probably have a more refined idea of it now. Just gotta get through a couple other articles first.

  8. tieTYT says:

    Am I on step 3, 6 or 7: Once in a while I will change a method from private to protected if I want to test it in isolation. I also do this for fields once in a while if I want to “sense” through them. Sometimes I test getters, usually if the field they return changes over the unit’s lifecycle. But, I use a mocking framework and mock every dependency. Also, since I’ve used a mocking framework, I’ve never felt like my unit tests are brittle.

  9. Randolpho says:

    I think I’m still stuck on step 6. :(

  10. meisinger says:

    i think its clear that step 2 is actually repeated after 5, 6, and 7

  11. Erik Porter says:

    Still at step 0 and just fine with that. πŸ˜‰

  12. Gogole says:

    On phase 3 indeed, found myself changing access modifiers in order to write tests for methods.

  13. Simon says:

    Step 2 is option!

  14. Paul Batum says:

    This list is only true if you’ve been learning unit testing in a vaccum, right? By understanding this list, a beginner can skip some of these steps right?

    If not I’m afraid I must be still stuck at step 2 and not realise it… :/

  15. Siderite says:

    What comes before the zero step? I want to know my place.

  16. BjartN says:

    So what is your definiton of an effective unit test?

  17. 8. Start teaching other about effective unit testing.

    But I think I skipped step 3 and went straight to step 4. And step 5 was during step 2 — but I was using Mocks!, not those mamby-pamby dynamic mocks, or stubs, or fakes! I wanted CONTROL!

    Then I got over it and switched to fakes and I’ve been much more pleasant ever since.

    Now where does “Throw out everything I knew about TDD and adopt BDD” fit in? Oh ya, back a #7.

  18. Josh Grenon says:

    Great post! I think that we are in the 2nd stage at work right now. I’ll be sure to get them to the final stage as soon as possible! Thanks!

  19. G’day Karl, generalising a little bit, your post has revealed a pattern in my blogging…that the time I’ve got the most to say on a technology or methodology (phase 2) is *before* I learn anything really useful. Thanks for exposing my shame :-)

  20. karl says:

    That’s the difference between 6 and 7 :)

  21. 8. Realize that mocking everything under the sun is no less brittle than testing internals and privates :)

  22. karl says:

    You never have to apologize if you stay 1 phase ahead of everyone else :)

  23. Chris says:

    Think I’m still at 6 and a bit of 6b . . . I need that 6c πŸ˜‰

  24. Kent Sharkey says:

    What step do you apologize to everyone you’ve wronged again?

  25. Brian says:

    1b. Fight against doing it because it’s extra code
    1c. Try and throw the people promoting unit testing under the bus.

    5b/6b – Generate a gizillion interfaces that are strictly used for unit tests.

    6c – Discover a mocking framework that doesn’t depend on DI to create mocks and remove the gizillion interfaces that were strictly used for unit tests only.

    8 – Enjoy watching others figure out why you don’t have hardly any bugs over the course of the year.

    9 – Enjoy making a change to your code and only having to update the handful of tests that now fail because of the change of requirements.

  26. I think you are missing one.

    0 – What is unit testing?