Part 2: Testing

Part 2 of this book explores topics relating to the effective testing of software.

It covers topics (such as TDD) that are not wholly concerned with testing but that feature testing as a part of the overall activity.

The main focus is on tests that can be automated, whether at the code level or by automating the actual user interface.

A good suite of automated tests helps keep software soft by providing rapid feedback when things break. The longer a software defect (“bug”) exists for, the more costly it becomes.

Tests can become a costly maintenance overhead, which is why it is important to take a holistic view of testing, a subject which is also covered in these chapters.

An Introduction to Unit Testing With xUnit.net

THIS IS A SAMPLE PART OF THE UNIT TESTING WITH XUNIT CHAPTER

Unit testing is the execution of discrete pieces of code to perform some action; and then checking (asserting) to see if they behaved as expected.

The purpose of having a suite of unit tests (or any type of test) is to increase the level of confidence that the system is behaving as expected.

The distinction of “unit” is important: a unit test should only test a small discreet piece of code (e.g. a class) and not rely on concrete dependencies such as other non-primitive objects or external things like databases and files.

Qualities of Good Unit Tests

In addition to only testing a discreet “unit”, good unit tests posses a number of other qualities as outlined below.

Isolated and Independent

A given unit test should be able to be run at any time and in any order relative to other tests. When run it should not rely on the result/state of a previous test having been executed. Unit tests should also not rely on them being run on a specific server or network.

Repeatable

A given test should either pass or fail regardless of when it is run. The test should be able to be run an indefinite number of times, each time producing the same result (given that that the rest of the codebase stays the same).

Valuable

Any given unit test should add some value, i.e. if the test fails then the knowledge that “something is broken over there” should be of value to the development team. An example of a test that would add no value would be testing automatic property getters and setters; these are language features and should not be unit tested. Unit tests should only test custom code, not 3rd party or platform framework code.

Fast

Unit tests should execute quickly. They should be able to be run at any time by the developer and not hold them up for too long before they can continue coding. Unit tests that take too long to execute are likely to not be run as often as they should be which can result in defects existing for longer than they should do.

As a general rule, an individual unit test should execute in less than about half a second, though the specifics of the codebase and problem domain should be taken into account.

Trustworthy

The result of a test should be 100% reliable and the development team should not feel the need to doubt the results (e.g. by debugging the running test).

Readable

As with production code, test code should be as readable and of as high quality as production code.