4 ms·
The code and the tests go together. You don't just make a pile of code, and a pile of tests, and hope they all go together right. You have some big tests that
by Periodic 17y ago
The code and the tests go together. You don't just make a pile of code, and a pile of tests, and hope they all go together right.
You have some big tests that are general and test that all the components work together, but for each component you have lots of little tests, and if you are going to change the component you change the tests FIRST. That's TDD.
You deliberately break the tests before you change one line of the actual code.
- wvenable 17y agoSee, I think the value in tests would be that they are reusable. If you're smart enough to write a test for a situation, then you're smart enough to code for that situation in the first place (and conversely if you miss an edge case in code, you're just as likely to miss an edge case in testing). If you're constantly rewriting your tests -- what's the gain? Now certainly writing everything twice is actually a great way to catch errors. NASA does that with the shuttle. But I wouldn't argue that its faster. I prefer to just liberally sprinkle my code with run-time assertions. We have a small defect rate even after pushing out massive structural changes to the application. The bugs that we do have tend to involve an unpredictable set of conditions that no automated test would ever be written to find.