A unit test is just more code, not really an explanation of what you're trying to achieve. It looks to me as if unit testing is being overzealously applied to make up for a lack of take-up from design-by-contract techniques. And failing. Everywhere I see it being used in a corporate environment, it's all about ass-covering, "not breaking the build" (haha as if), following procedure ("we do it this way here"), etc. rather than any intelligent application of unit testing as per Riven's usage - that is, just testing a few little odd bits here and there that are complicated.
If you seen this applied the way you described here, it wasn't right. Unit testing is mostly used in TDD (test driven developpement) and it has been demonstrated that it can cut down the total developpement time of rather big project by factor 2. On corporate project, assuming that every programer isn't a A+ class, it helps to avoid 4000 lines methods and enforce decoupling of the different parts of the application since it force the application to be testable, it's a mean to obtain quality, not just "ass-covering".
Here's a good reference :
http://www.agiledata.org/essays/tdd.htmlEnjoy
Show Posts
