Principles

Minimum single test time

The Time taken to run a single unit test should be as less as possible. This is a must to allow test driven development. Slow one time initializations don't affect the time taken to run the entire suite of tests and don't show up in the build time. This masks a niggling problem of high price paid every time a single test is run.

Bug discovery test

When a bug is reported the developer should reproduce this bug by writing a unit test instead of manually clicking through user interface, debugging the application or writing log statements. The application layer against which the test is written and its scope should be such that one can reproduce it with certainty. This principle shouldn't be confused with well known principle of TDD which is to write a failing test before writing production code.

Green editor box

Both IntelliJ, Eclipse and ReSharper provide an indication about status of class, configuration file in a single box at the top right corner. Lets call it status box. It is also supported by various error, warning and suggestions in the editor bar below it. The programmer should strive to keep it green all time. One should also ensure that all programming artifact are treated the same way.

Single click test run

Task oriented build

Concentrate complexity to spread simplicity

Rails is a good example of this.

Build is executed more than read

Use test specific class for testing generic behavior

Look at the emails and other material to see what the fundamental principle behind a particular design approach is.

Fail with all errors (not same as fail fast). Used in build, providing message to user.

Use convinient data