DEV Community


Discussion on: Does TDD slow you down or help you go faster?

n_develop profile image
Lars Richter

I like test-driven development a lot. And I am in the fortunate position of being able to do TDD at work as well. So there are no managers telling me to just ignore the testing or stuff like that. I have worked at other places, where no tests were written at all. And that's not a good place to be in. Ask me how I know. 😉

I think TDD can slow you down. Depending on how dogmatic you stick to it. When I say "I'm doing TDD", you have to take it with a grain of salt. One of the "laws of TDD" is

You are not allowed to write any production code unless it is to make a failing unit test pass

And to be honest, I don't do that all the time. I will totally add attributes to my controllers (in my C# code) without writing a test for it. Or when it comes to database access, I will write the (EntityFramework) DbContext without a single test for it. Mainly because I don't think tests like that add enough value.

But when I get to business logic, I do like to write my code in a test-first manner, because I think it makes me go faster. Sure, if I write my tests last, my production code might be done faster, but I still need to write tests. And in the end, I need to get deep in the code I have written hours (or maybe even days) ago, to find the right test cases. And that will take longer than writing the tests before writing the production code.

toureholder profile image
Touré Holder Author • Edited

Right! Having to go back to code you've written for days to find the right test cases definitely seems time wasteful to me, but what if one does a test-last approach with very small cycles of implementing then testing (instead of testing everything when your "done")? Do you suppose that would take any longer than TDD?

n_develop profile image
Lars Richter

As long as you keep your testing cycles short and crisp, I assume there won't be a noticeable difference.


... I think there is still one important difference. When doing TDD (meaning test-first), there is, at least in my opinion, a hugely underrated step saying

Write a test and watch it fail

For me, this step is essential. Watch the test fail. It's the only way to validate that

  1. you are about to write code that is in fact needed.
  2. you made the right assumptions while writing the tests
  3. you implemented your test correctly

When doing "test-last", you are losing these advantages. So in the end, your assumptions might have been wrong for a couple of test cases and that can slow you down as well.

Forem Open with the Forem app