TDD and Naming Part 3: Customized Assertions

Listen to this post

Unit testing frameworks, which are the most common tools used by developers to conduct TDD, come with pre-made assertions that can be used to verify the behaviors being specified. Typically, these include assertions such as:

“areEqual()” (value comparison)
“areSame()” (entity comparison)
“isNotNull()”
“contains()”

Developers should not limit themselves to these pre-made assertions. The creation of custom assertions, which can be private methods on the unit test itself, or static methods on a class designed to sport them, is a best practice. Here are some advantages.

  • They yield more expressive tests. The custom assertions are named using domain language, and to explicitly express the specified behavior. For example: “employeeWasAddedToDatabase()”.
  • The tests can end up shorter and more focused, and therefore easier to read.
  • You have more control over the message emitted in the test runner when the test fails. One place where tests prove their value is when they fail. The value can be increased by controlling the information they given when this happens.
  • They can be used to eliminate redundancies across tests.

Custom assertions are implemented using the canned assertions, and so they are equally reliable.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.