Deriving Team Standards for TDD

You’ll want to make sure your team approaches TDD with a few simple standards. Don’t let these standards be a barrier to getting started, however. Like everything else in Agile and TDD, the goal is to put a little into place and then continue to refine things as you go forward.

Here are a few of the key things you’ll want to agree upon:

• Unit testing tool (Google Test, CppUTest, or CppUnit, for example). Over time, you might migrate to a better tool if one emerges. At that point, it’s OK to do so incrementally. For now, though, find a unit testing tool that suits your team best and stick with it until you have good reason not to.

• Other tools, including mock frameworks and code coverage tools.

• Integration standards. Team members should agree what level of testing occurs before integrating code to the source control system. Ideally, developers should run all unit tests, as long as it isn’t a barrier to frequent integration (because of existing legacy system problems). You should never permit the check-in of failing tests.

• Test run standards. How slow can tests be? Can tests spew output onto the console (ideally not)?

• Failure process. When the build breaks, what should happen, and who needs to be involved?

• Disabled/commented-out tests. Generally, you’ll want to insist that these don’t get checked in. If a compelling reason exists, the committer should be required to provide an explanatory comment.

• Test naming forms. DoesSomethingWhenSomeContextExists isn’t a bad place to start, though you might want to avoid being dogmatic about the form. Conciseness and readability are important factors.

• Test structure. Are you following AAA? How are fixtures named? Where do tests physically go (both from a packaging and file organization standpoint)?

• Assertion form. Hamcrest or not? Are assertion comments OK?

Spend an hour in a meeting debating standards for your codebase, capture it in a short list of bullets, shake hands, and move on. Revisit the standard if you start to recognize conflict in the code. Standards are nice to have, but never let them be a barrier to moving forward.