While I still don’t always do test driven development when coding at work, I do a lot of it.
I don’t always do TDD
- If I know the exact shape of the code before I start, it’s easier to create that shape before writing tests. This happens a lot in web app development or when using generated code or certain framework. I still write the tests with the code though. I think this happens because the interface I’m constrained by isn’t where I start thinking about the problem. When working on libraries or within a method/framework I do still TDD.
- For spikes. If I have no idea how to approach something and just need to experiment. I don’t know what tests to write because I don’t know what to do.
Ok, let’s suppose you’re working on an algorithm
This is something I find to be a great starting point for TDD. It’s fairly obvious what the interface should be and most of the thought is on the implementation. It is also a great example because you’ll want to try the same test cases repeatedly as you work making TDD save time.
Great, what makes TDD harder?
It’s not really. The problem is when developers aren’t fluent in JUnit. If the person coding isn’t good at writing tests, that becomes another thing to think about. And when the mental load is higher, the task is harder. The solution to this is to practice writing tests and get better at it. Instead, some people merely complain that testing is hard and “expensive.” Which becomes a sell fulfilling prophecy.
An example of how this affects me
I can think of three testing libraries that I’m at different levels of comfort with. And my reaction to writing a test in them. (just a regular test, forget about TDD here)
| Library | Comfort level | Reaction |
|---|---|---|
| JUnit | Fluent | TDD, no problem. |
| HtmlUnit | I have enough experience to know how to do common things and where I’m likely to hit a problem requiring more time. (I’m using it to test an app I didn’t write which makes things harder). | While I’m comfortable writing tests, I’m limited for TDD. I can definitely use TDD when fixing a bug. But I couldn’t write a new screen that way. I need the app to work enough to make sure my HtmlUnit test is right. |
| Selenium | I know enough to know it changed a lot since I last used it. | While my comfort level is a lot lower than HtmlUnit, I have the same feeling about TDD. I could use it to fix a minor bug presuming there is enough app for me to test my Selenium code. (And yes, Selenium as an HtmlUnit driver now which probably accounts for the similarity in reaction) |
While I do have different feelings about TDD based on comfort level, one of the biggest differences is time. It would take me a lot longer to write a Selenium test than a JUnit test. That’s a sign that I need to practice/learn more/gain more experience. Which is a perfectly normal part of coding. We do need to plan for this. Telling your developers to test with a tool they aren’t fluent in and not recognize it takes longer is a perfect way to invite no tests, poor tests or the quality of the code slipping.
Why was I thinking about this?
I’m working with someone on what I thought was an outline. He suggested “I think a good way for us to communicate about these topics might be to first imagine … questions we’ll want to ask”. Kind of like TDD for an outline. Think of what the student needs to know and get the “curriculum” from that. I’ve never done that before and it was a lot harder than just writing an outline. And I think the reasons it is “harder” are the same as for people new to TDD:
- A new way of thinking – I’ve never written questions before the objectives before. People new to TDD aren’t used to thinking about how to test before they write the “real” code.
- Lack of experience with the “tool” – While I’ve written a fair number of questions, I’m by no means at the point that I feel fluent in doing so. I’m probably just under where I feel with HtmlUnit in terms of experience there. I know where many obstacles are but am still surprised often.
- More balls in the air – Just like thinking about both the tests and code in TDD, I had to think about both the questions and topics.
What is the takeaway
“Harder” doesn’t always mean harder. Sometimes it means you need more skills and practice. So if TDD seems “harder” to you, don’t run screaming. You’ll get there.