If a test fails as part of a regular test execution the entire team should drop what they are currently doing and make sure the problem gets fixed.

The Hello, world! of unit tests goes like this:

     void testDefaultConstruction()
     {
       Foo foo = new Foo();
       assertNotNull(foo);
     }

Make sure the build environment is configured so that the test classes doesn't make its way into production libraries or executables.

• Trivial is hard to define. It may mean different things to different people.
• From a black-box perspective there is no way to know which part of the code is trivial.
• The trivial cases can contain errors too, often as a result of copy-paste operations:

       private double weight_;
       private double x_, y_;
  
       public void setWeight(int weight)
       {
         weight = weight_;  // error
       }
  
       public double getX()
       {
         return x_;
       }
  
       public double getY()
       {
         return x_;  // error
       }

Consider the following public method:

     void setLength(double length);

To achieve this, provide a simple utility class that generates random values of the base types like doubles, integers, strings, dates etc. The generator should produce values from the entire domain of each type.

If the tests are fast, consider running them inside loops to cover as many possible input combinations as possible. The following example verifies that converting twice between little endian and big endian representations gives back the original value. As the test is fast, it is executed on one million different values each time.

    void testByteSwapper()
    {
      for (int i = 0; i < 1000000; i++) {
        double v0 = Random.getDouble();
        double v1 = ByteSwapper.swap(v0);
        double v2 = ByteSwapper.swap(v1);
        assertEquals(v0, v2);
      }
    }

As for ordinary code, it is a goal to keep the amount of test code as low as possible.

Consider this method that throws an exception if called with a negative parameter:

    void setLength(double length) throws IllegalArgumentException;

    try {
      setLength(-1.0);
      fail();  // If we get here, something went wrong
    }
    catch (IllegalArgumentException exception) {
      // If we get here, all is fine
    }

Some suggestions:

• Make class members immutable by establishing state at construction time. This reduce the need of setter methods.
• Restrict the use of excessive inheritance and virtual public methods.
• Reduce the public API by utilizing friend classes (C++), internal scope (C#) and package scope (Java).
• Avoid unnecessary branching.
• Keep as little code as possible inside branches.
• Make heavy use of exceptions and assertions to validate arguments in public and private API's respectively.
• Restrict the use of convenience methods. From a black-box perspective every method must be tested equally well. Consider the following trivial example:

          public void scale(double x0, double y0, double scaleFactor)
          {
            // scaling logic
          }
  
          public void scale(double x0, double y0)
          {
            scale(x0, y0, 1.0);
          }

  Leaving out the latter simplifies testing on the expense of slightly extra workload for the client code.

Consider for instance a class for parsing files of a certain type. Instead of picking a sample file from a predefined location, put the file content inside the test, write it to a temporary file in the test setup process and delete the file when the test is done.

The typical areas where it is hard to get full execution coverage is on error and exception handling dealing with external resources. Simulating a database breakdown in the middle of a transaction is quite possible, but might prove too costly compared to extensive code reviews which is the alternative approach.

    Handle handle = manager.getHandle();
    assertNotNull(handle);

    String handleName = handle.getName();
    assertEquals(handleName, "handle-01");

    Handle handle = manager.getHandle();
    assertNotNull(handle);
    if (handle == null) return;

    String handleName = handle.getName();
    assertEquals(handleName, "handle-01");

A failing test may indicate that the code contains errors, but a succeeding test doesn't prove anything at all.

The most useful appliance of unit tests are verification and documentation of requirements at a low level, and regression testing: verifying that code invariants remains stable during code evolution and refactoring.

Consequently unit tests can never replace a proper up-front design and a sound development process. Unit tests should be used as a valuable supplement to the established development methodologies.

And perhaps most important: The use of unit tests forces the developers to think through their designs which in general improve code quality and API's.