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.
Let’s make it possible to have multiple assertions per test, while keeping the feedback actionable.
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!
Brian Doll is a business-focused technologist who has been building things on the web for over 13 years. He has extensive experience in retail, media and financial service industries in both start-up and large enterprise environments.
He enjoys speaking on lean engineering, web application performance and systems architecture. Having been inspired by Ruby and reinvigorated by Rails, Brian has been an avid contributor in the Ruby/Rails community since early 2007.
Additionally, he is a husband, father, thought worker, tree-hugging, music-loving, punk, atheist, non-conformist, optimist, Quality seeker. Phew! Here you'll find a mix of thoughts on fitness (Crossfit, Paleo foods), philosophy and programming (Ruby, Rails and other goodies).