3 ms·

Dr. Richard Hipp (the main author of SQLite) once said in a tech talk that one of the big advantages of having thorough automated testing is that you can freely

Dr. Richard Hipp (the main author of SQLite) once said in a tech talk that one of the big advantages of having thorough automated testing is that you can freely optimize or replace individual components without being held back by worrying about unknowingly breaking something. (I think he said they've replaced the query optimizer several times.) This fits my experience, and I think it's what Michael Feathers is getting at when he defines legacy code as "code without tests". I'm not convinced that letting testing drive the design process is always a good idea (though the benefits of test-informed development are harder to argue), but having thorough tests is usually a huge win. Having thorough tests isn't free, particularly with good coverage, but it usually pays for itself in the long run. > I also avoid mock objects like the plague, aggressively preferring to either build the interface to be testable in the first place, or failing that, adding some hooks in the tested code itself, rather than trying to push it onto the code from the outside. Same here. Mock objects can be useful when trying to retrofit tests onto existing code, but that's just a concession to practicality. Reworking a huge, untested code base to make it testable can be a great way to introduce bugs unless done with extreme caution. (That's the main topic of Feathers's book, FWIW.)

jerf 17y ago
"I'm not convinced that letting testing drive the design process is always a good idea" Yeah, I gave full-on TDD the college try and did not like it. IMHO it might not be a bad crutch for those who are still new to code design issues, but it just involved too much closing my eyes to issues that I knew would be a problem in the future and willfully blundering into design traps I knew about in advance. Using it to learn about those issues is probably a good thing, but it must eventually be discarded. I still do sometimes write the tests in advance when it makes sense (usually those same low-level things I referenced in my first post) but as a general principle I don't find it gives me the best APIs in the end.
- hello_moto 17y ago
  I'm 50-50 on TDD. But I suppose that's because of the people around me examples I mentioned somewhere in this thread. On one side, TDD made sure that your code is designed to be testable at maximum level. That means: developers have no excuses to design their code to be testable (whether it uses DI, less coupling, or whatnot). One thing about developers is that they're too self-confident that their code is not buggy. When bugs found, they just fixed it and didn't bother to analyze and learn from mistakes. So what happened when they wrote untestable code and suddenly 2 weeks later there were bugs manifest due to whatever reasons? If the untestable code is easy to refactor, management probably won't mind a bit of hickup in their schedule. But if it takes a wee bit more time? I think TDD is good when the developers are inexperienced. But at the same time, it's human nature to be lazy and made mistakes (or underestimate things). I don't know the best answer whether TDD is good or not.
  - silentbicycle 17y ago
    Right. The tests come from the same mind(s) that wrote the code. Some kinds of bugs won't occur to them at the time, and may also be missed by the corresponding tests. Testing upfront is just another tool, whether by unit tests, static typechecking, or a REPL. Often useful, but not a panacea.
Erwin 17y ago
Note that the vast majority of the sqlite tests are functional tests written in TCL and are not "real" unit tests. His test test stuff like "does select (this, this, this) return that under these circumstances. There's some test setup stuff written in C and maybe C-level interface tests, but I think the functional tests are what lets him modify his optimizer, rather than some unit tests which are tightly bound to a specific implementation.
- silentbicycle 17y ago
  You're right. I think he and I both are guilty of lumping several kinds of tests (functional/acceptance, integration, etc.) under "unit tests".

jerf 17y ago

"I'm not convinced that letting testing drive the design process is always a good idea" Yeah, I gave full-on TDD the college try and did not like it. IMHO it might not be a bad crutch for those who are still new to code design issues, but it just involved too much closing my eyes to issues that I knew would be a problem in the future and willfully blundering into design traps I knew about in advance. Using it to learn about those issues is probably a good thing, but it must eventually be discarded. I still do sometimes write the tests in advance when it makes sense (usually those same low-level things I referenced in my first post) but as a general principle I don't find it gives me the best APIs in the end.

hello_moto 17y ago
I'm 50-50 on TDD. But I suppose that's because of the people around me examples I mentioned somewhere in this thread. On one side, TDD made sure that your code is designed to be testable at maximum level. That means: developers have no excuses to design their code to be testable (whether it uses DI, less coupling, or whatnot). One thing about developers is that they're too self-confident that their code is not buggy. When bugs found, they just fixed it and didn't bother to analyze and learn from mistakes. So what happened when they wrote untestable code and suddenly 2 weeks later there were bugs manifest due to whatever reasons? If the untestable code is easy to refactor, management probably won't mind a bit of hickup in their schedule. But if it takes a wee bit more time? I think TDD is good when the developers are inexperienced. But at the same time, it's human nature to be lazy and made mistakes (or underestimate things). I don't know the best answer whether TDD is good or not.
- silentbicycle 17y ago
  Right. The tests come from the same mind(s) that wrote the code. Some kinds of bugs won't occur to them at the time, and may also be missed by the corresponding tests. Testing upfront is just another tool, whether by unit tests, static typechecking, or a REPL. Often useful, but not a panacea.

Erwin 17y ago

Note that the vast majority of the sqlite tests are functional tests written in TCL and are not "real" unit tests. His test test stuff like "does select (this, this, this) return that under these circumstances. There's some test setup stuff written in C and maybe C-level interface tests, but I think the functional tests are what lets him modify his optimizer, rather than some unit tests which are tightly bound to a specific implementation.

silentbicycle 17y ago
You're right. I think he and I both are guilty of lumping several kinds of tests (functional/acceptance, integration, etc.) under "unit tests".