On 12/11/06, Andrew Lentvorski <[EMAIL PROTECTED]> wrote:
Chuck Esterbrook wrote:
> Regarding unit tests, I have found them to be:
> - great for standalone methods
> - good for standalone classes
> - not so great for OO frameworks.. When I start needing mock objects I
> feel the ROI on writing test code plummets
Unit tests aren't always about the *original* developer ROI.
At this point, if some library or framework I am looking at doesn't have
unit tests for regression testing, it's just not a viable choice.
What invariably happens is that I get a framework/library/etc, and I
start using it. At some point, something weird happens, and I have to
isolate a testcase.
If the system already has regression tests, I know that my test will go
into the system, and *I don't have to maintain it anymore*.
Personally, I find writing automated unit tests to be useful the moment
I start debugging. At that point, I have a codebase with defined
behaviors and the bugs tend to focus the tests on the areas which most
need testing.
I do have tests for the framework level, but I'm not clear if I should
be calling them "unit tests" or not. Rather than use mock objects, I
have tests that make use of the framework in concert. So one test
might work with classes A, B and C at the same time (not A, MockB and
MockC).
Do I call that a unit test? Or simply a regression test? Or something else?
-Chuck
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
