Gunther Birznieks writes: > the database to perform a test suite, this can get time consuming and > entails a lot of infrastructural overhead.
We haven't found this to be the case. All our database operations are programmed. We install the database software with an RPM, run a program to build the database, and program all schema upgrades. We've had 194 schema upgrades in about two years. > unit testing being done on the basis of writing a test class for every > class you write. Ugh! That means that any time you refactor you throw away > the 2x the coding you did. By definition, refactoring doesn't change observable behavior. You validate refactorings with unit tests. See http://www.refactoring.com > To some degree, there should be intelligent rules of thumb as to which > interfaces tests should be written to because the extreme of writing tests > for everything is quite bad. Again, we haven't seen this. Every time I don't have unit tests, I get nervous. How do I know if I broke something with my change? > Finally, unit tests do not guarantee an understanding of the specs because > the business people generally do not read test code. So all the time spent > writing the test AND then writing the program AND ONLY THEN showing it to > the users, then you discover it wasn't what the user actually wanted. So 2x > the coding time has been invalidated when if the user was shown a prototype > BEFORE the testing coding commenced, then the user could have confirmed or > denied the basic logic. Unit tests aren't about specs. They are about APIs. Acceptance tests need to be written by the user or written so the user can understand them. You need both kinds of testing. See http://www.xprogramming.com/xpmag/Reliability.htm Rob
