5 ms·
But then I think the approach is the wrong one. In TDD you are not required to write a lot of test and hope that they magically work in the future. Instead a sm
by zumda 15y ago
But then I think the approach is the wrong one. In TDD you are not required to write a lot of test and hope that they magically work in the future. Instead a small test to do one thing should be written, and then write enough code to make it pass.
For example lets take a simple newsletter signup form with only a field to enter an email address.
Now you shouldn't write a test to see what happens when you enter an email, a wrong email, if the confirmation email is sent, etc. Start with the simplest case: "If I fill in my email, and I press klick, then it should show me a confirmation that I singed up." Not more. Now make that pass, and you have working code!
Now you can add tests that verify that a wrong or empty email is rejected, now make that pass. More working code!
With TDD you should never end up with a lot of tests and no code that solves the problem. In that case you are actually writing too many tests and not enough code.
- bruceboughton 15y agoSure, if you need training wheels on your bike...
- prodigal_erik 15y agoWhich we demonstrably do as an industry. When neither NASA nor Knuth can write 100% correct code, the rest of us can't reasonably expect to pull it off. Human beings doing meticulous work make lots and lots of mistakes, and I welcome any feasible tactic that stops mine from being released. Sure, automating "I got a confirmation after pushing the button" seems hokey on day one (it's not as if you'd otherwise commit and go home before having seen it work) but somebody is eventually going to make a change that unexpectedly breaks it, and I want to know about it.
- bruceboughton 15y agoI'm not debating the importance of tests, but rather of the test-driven approach. I can write code and then write tests (or intermingled) and satisfy your point. I don't have to switch my brain into this wierd test-driven approach to do that. TDD zealots don't seem to understand that.
- prodigal_erik 15y agoPeople just assume older code works. I'm regularly finding stuff we've had in production for months that never did what it was supposed to. You could go back and write all the same tests after the code is done, but I find it extremely unlikely that anyone will actually reach the same degree of test coverage (I know I for one never have). And even if you're one of the rare few who will pay down this technical debt eventually, it takes away quite a bit of the value of the tests to muddle through all the coding work without them.