On Apr 28, 2006, at 2:53 PM, Ben Fowler wrote:
I've certainly found 'make check' useful on one occasion in the past.
IMHO "unit tests" sometimes means different things to different
people: I have heard it said that unit tests should be written to
cover every tranche of new code; unti tests should be run (at 100%
success) at every compile; unit tests should be run before check-in.
Whilst there is such as thing as too much process, modern thinking is
that unit testing - test infected - is the human readable term, is the
way to provide an uptodate design, in the form of a living document.
Actually... rather than "test infected" we really want to be getting focused on "test driven development"
However, to point out things, you've hit some mix of features and uses of unit tests.
For definition/aspects of ...
Basically, a "unit test" tests some unit of software, usually a module of some sort. It will run through API's and such to ensure that base functionality is as expected.
Then we have "integration test", where pieces are put together and system is checked for overall operation.
"Regression tests" are those that are done to make sure that things that were once fixed stay fixed, and don't "regress" to be broken again. Often unit tests can be run as part of regression testing.
Once one has unit tests in, maximizing their benefit is good. Running all unit tests before checkin is a very good thing. Running them each and every developer build is even better.
Test Driven Develop goes on to say that you shouldn't bother writing anything that you don't code the unit tests for first. If you can't create a unit test for some function, then you either don't need that function, or don't understand what you're doing.