One assertion per test

This is a very common TDD guideline. Jay Fields posted a good summary of why he feels one assertion per test is a good practice. If you read closely, however, you can see that the main reasons Jay doesn’t like multiple assertions per test is that the feedback provided from the test suite is usually poor.

There are circumstances, however, where you may choose to make multiple assertions per test. Personally, I use shoulda in my Ruby projects. One feature I really love are the nested contexts. The way these work, however, is that each context in your scope have their setup methods run in order, prior to executing each should statement. In some testing scenarios, you may find that you’re setup blocks are taking a good amount of time to run. If you were to have similar assertions in one test, you can speed up that test class quite a bit.

The goal

Let’s make it possible to have multiple assertions per test, while keeping the feedback actionable.

  • All assertions in the test should be run
  • All assertion failures should be reported
  • Each assertion should report actionable feedback

A solution

I’ve implemented assert_each as a way to specify a list of assertions that meet our goals. Add this to your test_helper.rb and enjoy!



Discussion, links, and tweets

I run marketing at GitHub. Follow me on Twitter for more musings from the ether.

© 2007-2014 Brian Doll