3 ms·
One is also supposed to never change the test after it has been etched in stone, especially in BDD, but good luck getting people to follow that rule, especially
by MostAwesomeDude 15y ago
One is also supposed to never change the test after it has been etched in stone, especially in BDD, but good luck getting people to follow that rule, especially in this modern age of Agileish development cycles. TDD, if practiced exactly as originally described, ends up being a drain on resources. You care more about the tests than about the code being tested.
As a now-classic example, observe a TDD master struggling with Sudoku: http://xprogramming.com/articles/oksudoku/ http://xprogramming.com/articles/oksudoku/
- gte910h 15y ago> to not test code which has not yet been written. You're not doing TDD if you're writing tests afterwords, you're just writing unit tests. I'm not trying to dissuade you from that but just pointing out you're using the wrong term if you're not doing that. I'm not a TDD proponent for most types of work that aren't heavily interfaced based, webservices to iPhone apps, I TDD them, but the actual app internals? Only on certain parts.
- samstokes 15y agoWait, I've never seen anyone recommend never changing the test - of course you may have to change it, if requirements change and it now tests the wrong thing, or if you deleted the code it was testing, or if there's simply a bug in the test code. BDD encourages higher-level, whole-system tests alongside low-level unit tests, so the conditions for changing a behavioural spec should (hopefully!) happen less often, but I still don't see why you would avoid changing a test if it was wrong or no longer relevant.