…re normal, but having to stop each time to write a test at the start just makes each problem worse. What’s far easier is writing your code, manually doing some QA tests, and then writing automated tests that mimic those situations, specifically for the code you wrote. With proper tests in place, you can freely move on to the next feature or refactor without being a…
Yeah, I’ve done that, I still have tests that started out that way. Trouble is, I can’t be sure if those tests might still pass even if I make a change that should theoretically break them. I assume they pass for the right reason, but because I haven’t seen them fail, I don’t actually know.
Another problem: I might forget to write an automated test for something I tested “manually,” e.g., at the console I test negative numbers and 0 but I write an automated test for positive numbers only.
Of course it’s still possible to forget to test for something with TDD. But you have the confidence that if future changes to the source cause the program to function incorrectly in what your tests test for, then at least one of your tests will fail, alerting you to the problem.