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

Unit Testing with Minitest: Specs

By

Unit Testing with Minitest: Specs

This article is part of a series, for more information see Unit Testing with MiniTest.

The interface thus far is more or less a clone of the old Test::Unit classes. MiniTest also includes a set of spec methods, allowing you to write RSpec-style pseudo english tests. This is implemented in the core MiniTest library, no libraries like RSpec or Shoulda are required.

Expectations

Since specs require adding methods to just about every object and generally mucking with things internally, they're not turned on by default. In order to use specs, require minitest/spec. Once this is done, you'll have access to methods like "string".must_be_instance_of to specify your assertions, which read much more cleanly than the old assertion methods.


#!/usr/bin/env ruby
require 'minitest/spec'
require 'minitest/autorun'

class TestSpecs < MiniTest::Unit::TestCase
  def test_instance_of
    "test".must_be_instance_of String
  end

  def test_using_assertions
    assert_instance_of String, "test"
  end
end

In addition to the must variations, there are wont variations that have the logic reversed, just like assert and refute from the MiniTest assertions. They won't be mentioned below, but each expectation has an inverted form.

Also note that RSpec has more of a DSL to fully define specs using words like "describe" and "it," but those will be covered in a later article. This article covers the expectations only.

Expectations

Each of these expectation methods can be used on any object after the minitest/spec file has been required, though they only really make sense inside of an instance method of a Minitest::Unit::TestCase class. As each of these wraps an assertion, the function of each won't be described here, but an example of its usage will be given.

Each of these methods can also take a message as their last parameter. Whether you use these is up to you. The style of tests you write with spec-style expectations instead of assertions is much easier to read, and will likely already read the same as the message you'll write. Though only an automatically generated message will be printed from the spec runner. This is a matter of choice.

  • must_be(op, b) - This wraps assert_operator, and can be used like some_num.must_be :>, 10.
  • must_be_close_to(num, delta) - Wraps assert_in_delta. a.must_be_close_to 10.3, 0.001.
  • must_be_empty - Wraps assert_empty. [].must_be_empty
  • must_be_instance_of(klass) - Wraps assert_instance_of. "test".must_be_instance_of String
  • must_be_kind_of(klass) - Wraps assert_kind_of. 10.must_be_kind_of Numeric
  • must_be_nil - Wraps assert_nil. obj.some_method.must_be_nil
  • must_be_same_as(b) - Wraps assert_same, object acts as the first in the argument list so it will receive the == method. a.must_be_same_as b
  • must_be_silent - Wraps assert_silent. Remember that this doesn't take any subprocesses into account, only output produced within the Ruby program itself.
  • must_be_within_epsilon(b, epsilon) - Wraps assert_in_epsilon. a.must_be_within_epsilon(b)
  • must_equal(b) - Wraps assert_equal. a.must_equal b
  • must_include(b) - Wraps assert_includes. This will fail if the object doesn't have an include? method as well. [1,2,3].must_include? 2
  • must_match(reg) - Wraps assert_match. "test".must_match /^te/
  • must_output(str) - Wraps assert_output. some_method.must_output "test"
  • must_raise(exc_class) - Wraps assert_raises. some_method.must_raise SomeError
  • must_respond_to(msg) - Wraps assert_respond_to. "test".must_respond_to :split
  • must_throw(sym) - Wraps assert_throws. some_method.must_throw :error
  1. About.com
  2. Technology
  3. Ruby
  4. Advanced Ruby
  5. Test-Driven Development
  6. Unit Testing with Minitest: Specs

©2014 About.com. All rights reserved.