The Philosophy of Unit Tests

Testing Isolated Functional Units

The individual tested units should, if possible, be of smallest size and independent of one another. You
should choose as units the smallest unit that supplies a result that can be checked. Ideally, the units
should not access each other. However, this requirement is really an ideal situation, and not always
practical. In any case, the tests that run one after the other should not work with data or objects that
were already changed by another test.
Test small code units provides different advantages:
In the case of an error, the problem can be easily localized if the unit is very small.
Ideally, an error cannot influence other tests in a test due to the isolation requirement.
Simple unit tests require less effort than complex test scenarios.
Testing During Development
Unit tests are executed regularly during development. This has the consequence that test phases
cannot easily be shortened or even discarded as in the classic case where testing occurs only after
development.
Precise Specifications Through Testing
Unit tests force you, the developer, to give precise definitions as to what a particular procedure should do
and which return values it should supply. If you cannot think of any unit test for a particular procedure,
this could be an indication that you should rethink the specification for this procedure.
Conversely, it is a good idea to firstly define unit tests for a procedure and then to implement the
procedure. In any case, the implementation of unit tests will help you to specify your procedures more
precisely and to find out whether the implementation actually matches the specification.
Better Modularization Through Testing
If you attempt to split your test unit into units that you can test independently of one another, you will
achieve a higher degree of modularization. While you are designing your unit tests, you will notice
where coding is not sufficiently modularized and you will adapt it accordingly. In this way, your
productive coding will be better.
Systematic Testing
Unit tests are systematic. You ideally cover all parts of a test unit and the tests are always executed
with the same test data. This has many advantages as compared with irregular tests that developers
execute anyway: No test cases are lost, you can navigate without any difficulty to the problematic code
lines after the test and do not have to search through lines of code as is the case if you are working
with traces.
Unit Tests as White Box Tests
Unit tests are typical white box tests, which only the developer himself/herself can execute. The
developer knows his or her coding so well that he or she can test the smallest functional units. The
individual tests may appear trivial to you and may not appear worth the effort. Together, the unit tests
provide you with the assurance in the case of full test coverage and regular execution that everything
will still work after program changes if it was working beforehand.
Unit Tests Versus Debugging or Traces
Unit tests are automated. In the Debugger, you have to enter your test manually all the time. Therefore,
with unit tests as compared with debugging you always have the same test data at your disposal,
without extra effort, and you do not waste additional time in making preparations for a test run. Not to
mention that fact that it is not enticing in the Debugger to fill the variables required for the test over and
over again with the same data.
Unit Tests Versus Integration Tests
In comparison to integration tests, the unit for unit tests is very small, and unit tests occur very early on
during development. Their role is thus made even more important: Integration tests can be focused on
errors that occur through integration because the individual units are already tested before integration.
Unit tests show up errors in an early phase of the life cycle of a component. In this way, you as
programmer have considerably more time to correct them and it also saves others having to work with
your incorrect code.