Bob La Quey wrote:
The point that I am getting at here is that unit tests do
define the code. They define the units. If the code is very
poorly designed then the units are wrong.
That is true. However, unit tests are at levels other than the bottom, too.
Occasionally you do need to throw out a unit and all its unit tests.
However, you need to have unit tests above that level so that the new
code which replaces an entire unit is still known to be correct. And
the new unit needs to have its own unit tests.
Sometimes people call those higher level unit tests by the names of
behavioral, architectural, or acceptance tests.
Some large systems simply need to be ditched. One must
occasionally start over.
I have never seen evidence to support that assertion.
A large system is a body of working code. It meets user demands in some
way or it would be removed from service.
Unlike a real-world engineering system, software code is infinitely
malleable.
At worst, a new system can always be written such that the new code
gradually absorbs all of the tasks of the old system until the new code
can handle all the tasks, and the old system can finally be removed.
Is that more work than writing a new system by itself? Yes. By
definition you have to keep *2* code bodies correct simultaneously.
However, at all points you have code which addresses all the user
demands that all *older* code also addressed.
Unit tests are fine. But they do constrain.
Okay, agreed.
That
is their purpose. There are times when one will be
better off busting the constraints.
However, you should have tests both at the current level you are coding
at (you own unit tests for new code) and tests at the next level higher
than you are coding (these tests ensure that you aren't going backward
when you rip out the old section).
This should be true even if you are writing your own new code. You
should have high-level tests which ensure that the behavior of the
overall is correct, and you should have lower-level tests that ensure
that the behavior of functions are correct.
Besides, it's always fun to watch peoples faces when they say "Why don't
you use library X? It solves all those problems," run your units tests
against it, and it blows up.
C libraries are particularly guilty for some reason. They never seem to
have been tested.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
