Summary 169

One possible way to make sure it’s up to date is by automating the generation process:

•Have a known set of prefixes or postfixes on the API helpers’ names (helperXX for example).

•Have a special tool that parses out the names and their locations and generates a document that lists them and where to find them, or have some simple directives that the special tool can parse from comments you put on them.

•Automate the generation of this document as part of the automated build process.

Discuss changes to the APIs during team meetings—one or two sentences outlining the main changes and where to look for the significant parts. That way the team knows that this is important and it’s always on people’s minds.

Go over this document with new employees during their orientation.

Perform test reviews (as opposed to code reviews) that make sure tests are up to standards of readability, maintainability, and correctness, and ensure that the right APIs are used when needed.

Following one or more of these recommendations can help keep your team productive and will create a shared language the team can use when writing their tests.

6.6 Summary

Let’s look back and see what we can draw out from the chapter we’ve been through.

Whatever testing you do—however you do it—automate it, and use an automated build procedure to run it as many times as possible during day or night.

Separate the integration tests from the unit tests (the slow tests from the fast ones) so that your team can have a safe green zone where all the tests must pass.

Map out tests by project and by type (unit versus integration tests, slow versus fast tests), and separate them into different directories,

170

CHAPTER 6

Test hierarchies and organization

folders, or namespaces (or all of the above). I usually use all three types of separation.

Use a test class hierarchy to apply the same set of tests to multiple related types under test in a hierarchy, or to types that share a common interface or base class.

Use helper classes and utility classes instead of hierarchies if the test class hierarchy makes tests less readable, especially if there’s a shared setup method in the base class. Different people have different opinions on when to use which, but readability is usually the key reason for not using hierarchies.

Make your API known to your team. If you don’t, you’ll lose time and money as team members unknowingly reinvent many of the APIs over and over again.

The next three chapters will deal with practices you can use to make your tests more maintainable, readable, and correct (in the sense that they test the right things).

7

The pillars of good tests

This chapter covers

•Writing trustworthy tests

•Writing maintainable tests

•Writing readable tests

•Exploring naming conventions for unit tests

o matter how you organize your tests, or how many you have, they’re Nworth very little if you can’t trust them, maintain them, or read them.

The tests that you write should have three properties that together make them good:

Trustworthiness—Developers will want to run trustworthy tests, and they’ll accept the test results with confidence. Trustworthy tests don’t have bugs, and they test the right things.

Maintainability—Nonmaintainable tests are nightmares because they can ruin project schedules, or you risk losing the tests when the project is put on a more aggressive schedule. Developers will simply stop maintaining and fixing tests that take too long to change.

Readability—This means not just being able to read a test but also figuring out the problem if the test seems to be wrong. Without readability, the other two pillars fall pretty quickly. Maintaining tests becomes harder, and you can’t trust them anymore.

171