This is part of an ongoing series of posts about how to get started writing tests for Ruby on Rails. The series begins with an introduction and overview of the ideas behind testing.

© Celia Perez

At this point in the series, we have covered most aspects of unit testing in Ruby on Rails. We learned the basics both in Ruby and in Rails and discussed how to write meaningful tests. We set up fixtures to make working with sample data easier. We learned to write tests for ActiveRecord objects and their relationships, validations, additional attributes and callbacks.

The only thing we have not done is write tests for the custom methods in our Winery and Wine models (such as: location, find_newest, age, is_antique?). But I feel confident that you have the testing skills to make that an easy task.

To ensure that you have everything you need for writing unit tests on your own, in this section I want to expand on the assertions you can utilize for unit testing.

Basic Assertions So Far

We have discussed six of the most common assertions already.

• assert(boolean, message)
• assert_equal(expected, actual, message)
• assert_raise(exception, message) { block… }
• assert_nothing_raised(exception, message) { block… }
• assert_nil(object, message)
• assert_valid(activerecord_object)

More Basic Assertions

There are three more basic assertions that you may find useful.

• assert_not_equal(expected, actual, message)
• assert_not_nil(object, message)
• flunk(message)

assert_not_equal and assert_not_nil should be self-explanatory. They are simply the opposites of assert_equal and assert_nil.

flunk can be very helpful. It always fails. (It is the same as assert(false, message).) Why would an assertion that always fails be useful? Because you can embed it in loops and conditional statements. It allows you to perform more complicated boolean testing to decide if a test should pass or fail.

Let’s imagine that we have an application that is managing the inventory in both a store and a warehouse. The rules of our application should prevent a customer from purchasing an item that is completely out of stock, and should prevent the total inventory from falling below 5.

Could we write this another way? Absolutely, especially for such a simple example. Technically, you do not need flunk, but it can be useful among complicated conditions and make your tests easier to read.

Advanced Assertions

There is a second group of assertions that I have elected to call “advanced”. The reason: most beginner and intermediate developers will never need them. You can safely skim over these. Just know they are available if you ever need them. Do not worry if you forget them—the functionality they provide is also achievable through a combination of standard Ruby and the basic assertions.

• assert_match(pattern, string, message)
• assert_no_match(pattern, string, message)
• assert_in_delta(expected_float, actual_float, delta, message)
• assert_instance_of( klass, object, message )
• assert_kind_of( klass, object, message )
• assert_respond_to( object, symbol, message )
• assert_throws(expected_symbol, message) { block… }
• assert_nothing_thrown(message) { block… }

Here is a test method to illustrate how each of these assertions can be used.

Rare Assertions

There are four more assertions. They are extremely rare and their behavior can be replicated using other assertions. You will never need them. But for the sake of completeness, I will include them anyway.

• assert_same( expected, actual, message)
  same as: assert_equal
• assert_not_same( expected, actual, message)
  same as: assert_not_equal
• assert_operator( object1, operator, object2, message)
  same as: assert( object1.operator(object2) )
• assert_send([receiver, symbol, arg1, arg2], message)
  same as: assert( receiver.message(arg1, arg2) )