If you TDD at the highest level that makes sense, with a test that mirrors the requirements in the form of a user story rather than the implementation (e.g. of a new function) most of the comments in this article dont really make sense.
Yes, if youre not sure about requirements its too early to write the test, but it's also far too early to be writing any production code.
There arent any real benefits to test-after. The risks of writing a test that mirror an implementation are higher. The risk of undertesting is higher.
And, I've also noticed that people who are very thorough with test-after tend to over test.
Fr3dd1•5mo ago
perrygeo•5mo ago
This is where I've landed as well. Unit tests are for locking down the interface, preventing regressions, and solidifying the contract - none of which are appropriate for early stages of feature development. Integration tests are almost always closer to the actual business requirements and can prove direct value - ie only once the integration works, then lock it down with unit tests.
I've also toyed with a more radical idea: don't check your tests into the git repo. Or at least keep the developer tests separate from the automated tests. Think about it: what rule says that the tests used in development should go directly into the CI test suite? One is designed to help you navigate the creative process, the other is designed to prevent regressions. I think we do a disservice by conflating the two scenarios into one "testing" umbrella. During TDD, I need far more flexibility to redefine the shape of the tests (maybe it requires manual setup or expert judgement or ...) and I don't want to be hampered by a (necessarily) rigid CI system. Dev tests vs CI serve two completely different purposes.
Fr3dd1•5mo ago
perrygeo•5mo ago
No so with CI tests. Input and output are 100% specified and no manual intervention is even possible.
There are some problems where "correct" can never be well defined. Think of any feature that has aesthetic values implied. You can't just unit test the code, brush off your hands and toss garbage over the wall for QA or your customers to pick up!
I use this technique mainly to avoid an over-reliance on automated testing. I've seen far too many painful situations where the unit tests pass but the core functionality is utterly broken. It's like people don't even bother to run the damn program they're writing! Unacceptable and embarrassing - if encouraging ad-hoc tests and QA-up-front helps solve this, it's a huge win IMO.