Discovery
When doing unit tests, the biggest time ‘eater’ I find is the ‘discovery’ phase – the phase where you ‘discover’ how your test will test the code. This is the phase where you answer tough questions like:
- How will you inject your dependencies?
- what are the dependencies in the first place?
- How can you assert on the proper outcome?
- what is the proper outcome to test for?
- at what level should the test be? fake all the dependencies? maybe integration-like in nature? maybe it should even invoke the browser! but maybe not with a live internet connection needed.
- How do you even arrange the part(s) to be tested?
even if you’re doing TDD, this can be tricky, because you have even more possibilities open to you on how to go about answering these questions. if you’re testing legacy code, or you’re tasked with building something that is added on top of legacy code, you might need to find out what are the “rules” to work with the existing code that your new code must adhere to.
How long?
I’d say that once you’re done with the ‘discovery’ phase (the first one or two tests), writing new tests for this system will get siginificantly simpler (10% of the time it takes to write a discover phase test, or even 1%!).
In the real world, I’ve sometimes taken a day or three to write the first couple of tests for a new module in a system , with following tests taking 10 minutes or 1 minute to write.
after the discovery phase you’re left with:
- real world knowledge on how the system can and should be tested
- a repeatable technique you can teach other developers
- perhaps some simple test related infrastructure to make all this work
I see many projects thinking that testing takes a long time, because they do not realize that they are still struggling with the discovery phase. It is indeed a challenge to go past, but once you do, things are just… well, simple.
examples of ‘discoveries’ which might already be well known and so are ‘simple’:
- How do you test that an event is triggered by a class? (register to the even and set off a boolean flag)
- How do you test your JavaScript and ajax code? (jasmine or jsunit and selenium respectively)
Great post, Roy. I definitely agree, and this is something I’ve been thinking of lately as well. I often find myself doing all kinds of procrastination while write the initial few tests because they’re so damn hard to put down in words. Many times I open another file, a sketch and try to just imagine some calls I’d like to make, not thinking of what they’ll do or how I’ll verify them. This often helps in finding a tone for the API. Then I get the test down, and soon enough I’m taking notes to not forget all the ideas I have for tests. Finally, it all slows down and then it’s done
TDD is beautiful that way.
On a related note, I’d not recommend anyone use JsUnit. It was great in 2001, but it is discontinued and there are lots of better tools. One example is JsTestDriver.
Also, I put a lot of work into Sinon.JS to make testing “hard” stuff like XMLHttpRequest dirt simple. Check out the site (http://sinonjs.org) or the slides I made for a local XP meetup: http://cjohansen.no/talks/2011/xp-meetup/
Nice! I’ve felt this pain as well, and I’m starting to wonder if it’s a symptom of a bigger problem, that we start out designing our systems from an old-school/procedural mindset and we have to scale back, scale back, scale back, until we have something small and testable. And from there our tests drive naturally forward.
I wonder, though. Does it HAVE to hurt so much? I don’t know the answer; that’s why I’m asking. But I wonder if there isn’t a better way to start the design, that initial cut of the system, so that testing flows immediately from it and all the questions you just asked either become moot or become minimized such that they can be introduced and folded in as the tests roll forward. Hrm, I need to play around with this thought some more, it’s not done baking, I guess.
Good post. Thanks for the thought-provoke!
Great post. I thought about this too and I certainly agree. Even though it takes some time to figure it out the answers for those questions, it is absolutely worth it IMO. Sometimes I learn new ways while exploring answers to these questions.
[...] was reading http://7enn.com/2011/05/02/the-biggest-time-eater-in-unit-testing/ the other [...]