From the description of your scenario, it sounds like you have a long product life cycle etc.
I think your testing, especially regression testing and the amount of effort you put into it makes a lot of sense because your software is a long-term investment possibly even a product. I think you can "worry" about an API not having a test for it, and I do a bit, but I don't lose sleep over it. The reality is many APIs succeed OK without tests and maybe a few grumbles hear and there if and when things break. I've rarely seen a documented API break in such a significant way that either I programmed or used from someone else that I could not easily rectify it or go back to a previous version until it was resolved. ie major API changes usually have a way of being known anyway very quickly. Would API tests for every API in existance solve that? Could be, probably yes. But is it worth all the extra coding time for those tests? I don't think so. Not for all APIs. To each his own I guess. I agree with tests for some things, just not for all things including not all APIs. At 08:59 AM 1/26/2002, Rob Nagler wrote: >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 __________________________________________________ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
