I'd been writing tests for a while in a test-last development manner before learning how to develop software using the test-driven technique.
I find that many developers feel daunted by the practice of writing failing tests before writing the implementation/production code to make the tests pass, especially when they have little or no experience writing tests at all.
Since I can't go back in time and learn software testing using a test-driven development approach, I honestly don't know what it feels like and have thus decided to elicit the opinion of the community :)
Do you think it's better to introduce someone with no test writing experience to the practice of software testing with TDD right off the bat? Or is it better to learn TDD after becoming familiar with test-last development?
Top comments (8)
I think it is definitely easier to teach writing tests if you already have code to test. After they have learned how to write tests, you can just stop there. Dogmatic adherence to writing tests first (or last or at any other preordained time) is really nothing more than cargo cult coding. Write the tests first, last, or some where in the middle, it doesn't really matter as in the end the code is the same. All that really matters is that the tests get written.
I see your angle. I'm a big fan of TDD, though. For me it has definitely been the best way to obtain a high quality, high coverage test suite. It also helps me to write more modular and testable code and I spend less time "thinking" about what to test. But I do agree with you that it seems easier to teach writing tests if you already have code to test. I gave a TDD course last year at work and I taught the group how to test existing code before teaching TDD.
But if you're doing requirement analysis before writing the code, isn't it better to start with the tests?
And as for the original question, yes, it's fine to start with writing them last on a code you're already familiar with.
Yeah... starting with writing tests last on existing code seems the most intuitive route to eventually learning TDD. I was curious as to whether most people who are experienced in TDD see it that way too.
You should be doing requirement analysis before you write any code or tests. And once you have your requirements, it doesn't matter if you write the code or the tests first.
TDD is mostly useful for brand new code that is well spec'ed and has good design and requirement analysis in place. In the real world though we seldom have that so while we may try and start with the tests on a new project things get messy fast and scope creep happens or the requirements shift or the project simply takes too long and ends up diverging from what we thought we needed.
As has already been stated in the discussion: write tests whenever it is most suitable in the project but make sure you write them. Yes testing last can lead to issues with missing edge cases and tailoring the tests to the code written. But that is also part of learning how to write good tests.
That said I believe in never slavishly adhering to anything but rather looking at the context in which you are working and adjusting what you do to that context. Some things are inherently hard to test and while tests would be great if you don't have a dedicated team for testing then tests might just not happen for those trickier cases.
Should one practice juggling knives before juggling scarves?
Lol! So, I don't know if i'm looking too much into you comment, but are you suggesting that test-last development is actually dangerous and while TDD is especially tricky? (scarves are trickier to juggle that round solid objects like balls.)