Software testing: unit vs system tests

A question to keep in mind is what kind of defects would this test catch. If each test is written thoughtfully to improve software reliability, and if tests are removed when they no longer have value then the specific testing approach that delivers the most value for a particular project will be discovered over time.

In summary:
• Keep regression tests around for up to a year — but most of
those will be system-level tests rather than unit tests.
• Keep unit tests that test key algorithms for which there is a
broad, formal, independent oracle of correctness, and for
which there is ascribable business value.
• Except for the preceding case, if X has business value and you
can test X with either a system test or a unit test, use a system
test — context is everything.
• Design a test with more care than you design the code.
• Turn most unit tests into assertions.
• Throw away tests that haven’t failed in a year.
• Testing can’t replace good development: a high test failure
rate suggests you should shorten development intervals,
perhaps radically, and make sure your architecture and design
regimens have teeth
• If you find that individual functions being tested are trivial,
double-check the way you incentivize developers’
performance. Rewarding coverage or other meaningless
metrics can lead to rapid architecture decay.
• Be humble about what tests can achieve. Tests don’t improve
quality: developers do.