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
-
Archives
- July 2010
- April 2010
- March 2010
- February 2010
- January 2010
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
- May 2006
- April 2006
- March 2006
Would you mind I translate this article to chineses？
http://www.cnblogs.com/zhaorui/archive/2009/05/05/20090505_Phases_of_Unit_Testing.html
if you don’t like this, please tell me.
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.
@effective unit testing resource: The Art Of Unit Testing by Roy Osherove – practically free if you buy the e-version.
@Chris: Typemock Isolator
@Scott: Ain’t that the truth! NEVER TEST PRIVATES OR REFACTOR SO YOU DON’T HAVE TO IF IT’S THAT BAD!
8 – Discover BDD
9 – there is no 9 .. for now.
jose:
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.
What would be the most use pattern for testing settings the methods as public or setting them internal with internalsVisisbleTo?
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.
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.
I think I’m still stuck on step 6.
i think its clear that step 2 is actually repeated after 5, 6, and 7
Still at step 0 and just fine with that.
On phase 3 indeed, found myself changing access modifiers in order to write tests for methods.
Step 2 is option!
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… :/
What comes before the zero step? I want to know my place.
So what is your definiton of an effective unit test?
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.
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!
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
@Scott:
That’s the difference between 6 and 7
8. Realize that mocking everything under the sun is no less brittle than testing internals and privates
@Kent:
You never have to apologize if you stay 1 phase ahead of everyone else
Think I’m still at 6 and a bit of 6b . . . I need that 6c
What step do you apologize to everyone you’ve wronged again?
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.
I think you are missing one.
0 – What is unit testing?