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.
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?
As long as you keep your testing cycles short and crisp, I assume there won't be a noticeable difference.
But...
... 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
you are about to write code that is in fact needed.
you made the right assumptions while writing the tests
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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
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)
DbContextwithout 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.
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?
As long as you keep your testing cycles short and crisp, I assume there won't be a noticeable difference.
But...
... 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
For me, this step is essential. Watch the test fail. It's the only way to validate that
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.