Project Ramon

A learning journey from a Ruby noob perspective

Ruby’s MiniTest::Assertions_In_Action!



In yesterday’s post we covered a brief introduction into minitest a lightweight testing framework included in Ruby since 1.9.

We covered the setup and made sure our test suite was running properly before we ended last time. Today I’ll be covering what a few of the minitest libraries provide and finish out with an example of how I’ve been using it to document the Ruby standard library.

Minitest Components

Starting with minitest/pride, I think its best to just demonstrate what happens when this is required in our test files.




Here, we can see the default test output. Next up is with minitest/pride.




The result is us gaining a colorful presentation.

I also like using minitest/reporters to satisfy my formatting tastes, here’s a quick example of what this guides our test output to look like:

Here’s our test file, where I’ve added our reporters.


And here is what our test output now looks like:


Minitest Assertions

Here are a few assertions I have found useful so far, its pretty simple so I’ll just write briefly about some of them. You can find the full documentation here in the Ruby docs.

  • These first two methods will fail unless their results return a true value.
    1. assert(test, msg=nil)
    2. assert_block(msg=nil)
  • There’s the assert_empty(obj, msg=nil) method which fails unless obj is empty.
  • I use assert_equal(expected, actual, msg=nil) most frequently, as it will cause failure unless expected and actual are equal (==). This method prints the difference between the two if possible, during a failure.
    • We can also use assert_same(expected, actual, msg=nil) to achieve the same result.
  • assert_includes(collection, object, msg=nil) will fail unless our collection includes the specified object.
  • To test if our object is a kind of class, we can use assert_kind_of(class, object, msg=nil).
  • We can also test to see if a particular object is not empty with refute_empty(object, msg=nil).
  • And we can do something similar in our collections, this method will fail if our object isn’t in our collection.


The term “matchers” in MiniTest::Spec in regards to terminology, is completely different from “matchers” in RSpec. With that in mind, we’ll consider the Minitest word closest in meaning to Rspec matchters, which is “expectations”. Using the gem shoulda-matchers when using RSpec, these Minitest::Expectations have a familiar cadence to them. Instead of using object.should have(1) and object.should_not have(1) type of syntax, Mintest goes with the similar must and wont syntax.

Here’s a few quick examples in a similar fashion to our assertions above however, you can check out the Ruby docs for a more complete picture:

  • object.must_be_instance_of(string) will return a failure if the object isn’t of the String class in this case.
  • collection.must_be_empty will return false unless the collection is empty.
  • To check for equality, one method we could use is must_be_same_as. So person1_last_name.must_be_same_as(person2_last_name).
      You can also use the following for equality checks:

    1. must_equal, as in a.must_equal(b)
    2. must_match, i.e. g.must_match(h)
  • If our variable named number was assigned the integer 12, we could test that number isn’t 27 like so: number.wont_be(27)
    1. We could also do this, string.wont_be :empty?
  • Then there’s methods for not equal, does not include and will not match, here are those methods:
    1. apple.wont_equal(pear)
    2. ten_count_collection.wont_include(11)
    3. 'Franks'.wont_match('Tabasco')


So I promised I’d show you how I’ve been walking through the Ruby Library with testing. I took the approach of just covering each method’s functionality in a spec, but am open to new ideas to also include while working through Ruby’s Classes.

Here is what I’ve completed so far in the Array Class:

def test_array_first_returns_indicie_zero
  assert_equal(1, @array.first)
def test_array_take_returns_first_5_elements_in_itself
  assert_equal([1, 2, 3, 4, 5], @array.take(5))
def test_array_drop_returns_remaining_elements_after_n_has_been_dropped
  assert_equal([6,7,8,9,10], @array.drop(5))
def test_array_keeps_track_of_length
  assert_equal(10, @array.length)
def test_array_contains_elements
empty_array = []
  assert_equal(false, @array.empty?)
  assert_equal(true, empty_array.empty?)
def test_array_contains_specific_item
  assert_equal(true, @array.include?(7))
  assert_equal(false, @array.include?(11))

In case it isn’t completely obvious, I’ve just been going down the docs page for Array and pull out each method to test inside of a spec. I find that building these tests helps me recall what these methods do. Almost as easily as if I was writing a unit test in Rails.

If you know of any improvements I could make to improve upon my experience with this learning project of testing the standard library, feel free to comment!

Stay tuned…


Categories: Newbie, Ruby

Tags: , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s