I think you are missing one.

0 - What is unit testing?

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.

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

Think I'm still at 6 and a bit of 6b . . . I need that 6c ;)

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

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 :-)

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!

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.

So what is your definiton of an effective unit test?

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

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... :/

Step 2 is option!

Daily Reading List

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

Still at step 0 and just fine with that. ;)

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

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

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.

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

8 - Discover BDD

9 - there is no 9 .. for now.

@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!

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.

The7PhasesofUnitTesting单元测试的七种境界作者：KarlSeguin

1.以各种借口拒绝单元测试UnitTest，比较常用的是

Would you mind I translate this article to chineses？

www.cnblogs.com/.../20090505_Phases_of_Unit_Testing.html

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

#.think.in infoDose #28 (29th Apr - 8th May)

#.think.in infoDose #28 (29th Apr - 8th May)