TDD Tips

Here are a number of tips when writing tests.
  • AAA - Use an Arrange-Act-Assert pattern for organizing your tests
    • Arrange - This is where you do setup for your test. Create your expectations here.
      • Whenever you have the same steps/data for the Arranging stage repeated across many tests, consider using a Setup method to reduce the duplication of code.
    • Act - This is the action that triggers the specific item you are testing. It may be the construction of an object, a call to a method, or the raising of an event.
      • Sometimes the Act stage and the Assert stage are done as a single step, as in the case of checking for exceptions.
    • Assert - This is where you test that the action worked correctly. You compare your results against the expectations you established in the Assert stage. Some of the things to check for are:
      • The state of the object being tested (properties/fields)
      • The presence of certain exceptions
      • That certain methods were called (verify method calls)
  • One Assert Per Test
    • Each test is meant to prove one aspect of your code, so there will typically be just one Assert per test.
      • This isn't a hard-and-fast rule, because adding too many tests can cause as many problems as testing too many things in a single test method.
  • Improve Communication
    • Communication is improved when you can tell at a glance what a method or test result is all about. That can happen in two ways: Increasing clarity and reducing noise.
  • Increase Clarity
    • Avoid "meaningless" or ambiguous names for classes, methods and variables. (What is a "Foo" object again?)
    • Give your tests names that clearly indicate their purpose, such as public void Presenter_OnInit_Adds_Default_Content_When_Controller_Returns_Empty_Collection()
    • When running the test, a clear description can help diagnose when things are going wrong. Consider adding a [Description] attribute to your test; Description attributes will display in place of the name of the testing method when using some tools (such as the TestRunner in DevExpess). For example, you can add the following attribute to the sample test in the previous point: [Description("Ensure that the Presenter creates a default TestDrivenDNNModuleInfo instance when the Controller returns an empty list")]
  • Reduce Noise
    • "Noise" occurs in both the method/class names as well as in the actual code inside the test. "Noise" is anything that makes it hard to see important aspects or details in your code.
      • Only add the message parameter to your asserts if the assert itself is not clear.
  • Name the Expert
    • When developing as part of a team, knowing who wrote a test means that you can go straight to the person who knows the most about the test if/when something "breaks".
    • Use the Annotation attribute to identify the owner of the test:
      • [Annotation(Gallio.Model.AnnotationType.Info, "Owner: Dan Gilleland")]

Last edited Jul 19, 2010 at 3:33 PM by dagilleland, version 4


No comments yet.