1. Technology
You can opt-out at any time. Please refer to our privacy policy for contact information.

Test Driven Development in Ruby--Assertions

Using the Test::Unit Library of Assertions


The Test::Unit library comes with a variety of assertions to make writing tests much easier. However, since all the assertions follow the same pattern and do more or less what they sound like they do, there's no real learning curve here.

All assertions test if a condition is either true or false. Many assertions have both a true and false variant, to make your test read a little more like English. For example, there's an assert_equal, but there's also an assert_not_equal. In addition to these similarities, assertions will always have an optional message argument. The message gets printed when the assertion fails.

Assertions are easy to abuse. It's easy to use either too many or too few of them. Ideally, a test case should have only one or maybe a few assertions. In addition, these assertions should only be testing the same things. If you need assertions to test along several points of a complex action, you should be moving some of these assertions into tests of their own. A test should only be testing one part of the functionality--too many assertions and you've broken that rule.

You can also use too few assertions. When doing a complex action, it's easy to just stick an assertion after 5 or 6 lines of code and check the result. Unless the previous lines were already covered by other tests, this is not a good habit. Test everything, as long as those things weren't covered by assertions in another test. It's not uncommon to see as many assertions in a test as there are lines of code. However, since tests should be small and of limited scope, there shouldn't be too many either.

List of Assertions

All of these assertions have an implied message parameter as the last parameter unless otherwise noted.

  • assert(boolean) - The most generic of all the assertions. The assertion passes if the boolean expression evaluates to true. It's easy to avoid this one, but it's better to use one of the more expressive assertions when appropriate.

  • assert_block() {|| ... } - Evaluate the block and pass the assertion if the evaluation is true.

  • assert_equal(expected, actual) and assert_not_equal(expected, actual) - One of the most common assertions you'll use. The assertion passes if the expected value matches (or doesn't match) the actual value. The equality test is performed with the == operator.

  • assert_in_delta(expected, actual, delta) - This is the equivalent of assert_equal for floating point numbers. Since you cannot (or should not) compare floating point numbers with the == operator, this tests if the expected floating point number is within the delta range of the actual number.

  • assert_instance_of(klass, object) and assert_kind_of(klass, object) - Passes if the kind_of? or instance_of? methods on object return true for klass. The instance_of? methods returns true if the two objects are of the same type, and kind_of? returns true if the object is of the same type or an inherited type.

  • assert_match(regexp,string) and assert_no_match(regexp,string) - Passes (or fails) if string =~ regexp returns anything other than nil.

  • assert_nil(object) and assert_not_nil(object) - Passes (or fails) if the object is nil.

  • assert_same(expected, actual) and assert_not_same(expected, actual) - These are the same as assert_equal and assert_not_equal except they use the equal? method instead of the == operator.

  • assert_nothing_raised() {|| ... } and assert_nothing_thrown() {|| ... } - Runs the provided block and will pass if no exceptions were raised or throw.

  • assert_raise(*args) {|| ... } - Passes if the block runs and raises an exception of one of the types listed in args. This will pass on all other exceptions, though the exception may go unchecked.

  • assert_throws(*args) {|| ... } - Passes if the block runs and throws a symbol listed in args.

  • assert_respond_to(object, method) - Passes if the object will respond to the method listed in the arguments. This is achieved by using the respond_to? method itself.

  1. About.com
  2. Technology
  3. Ruby
  4. Advanced Ruby
  5. Test-Driven Development
  6. Test Driven Development in Ruby--Assertions

©2014 About.com. All rights reserved.