Expectations on State: Literals

An expectation can be made on the result of a computation:

expect 2 do
  1 + 1
end

Most objects, in fact, have their state expectations checked by invoking #== on the expected value with the result as its argument.

Checking that a result is within a given range is also simple:

expect 0.099..0.101 do
  0.4 - 0.3
end

Here, the more general #=== is being used on the Range.

Regexps

Strings of course match against Strings:

expect 'ab' do
  'abc'[0..1]
end

but we can also match a String against a Regexp:

expect %r{a substring} do
  'a string with a substring'
end

(Note the use of %r{…} to avoid warnings that will be generated when Ruby parses expect /…/.)

Modules

Checking that the result includes a certain module is done by expecting the Module.

expect Enumerable do
  []
end

This, due to the nature of Ruby, of course also works for classes (as they are also modules):

expect String do
  'a string'
end

This doesn’t hinder us from expecting the actual Module itself:

expect Enumerable do
  Enumerable
end

or the Class:

expect String do
  String
end

for obvious reasons.

As you may have figured out yourself, this is accomplished by first trying #== and, if it returns false, then trying #=== on the expected Module. This is also true of Ranges and Regexps.

Booleans

Truthfulness is expected with true and false:

expect true do
  1
end

expect false do
  nil
end

Results equaling true or false are slightly different:

expect TrueClass do
  true
end

expect FalseClass do
  false
end

The rationale for this is that you should only care if the result of a computation evaluates to a value that Ruby considers to be either true or false, not the exact literals true or false.

IO

Expecting output on an IO object is also common:

expect output("abc\ndef\n") do |io|
  io.puts 'abc', 'def'
end

This can be used to capture the output of a formatter that takes an output object as a parameter.

Warnings

Expecting warnings from code isn’t very common, but should be done:

expect warning('this is your final one!') do
  warn 'this is your final one!'
end

expect warning('this is your final one!') do
  warn '%s:%d: warning: this is your final one!' % [__FILE__, __LINE__]
end

$VERBOSE is set to true during the execution of the block, so you don’t need to do so yourself. If you have other code that depends on the value of $VERBOSE, that can be done with #with_verbose

expect nil do
  with_verbose nil do
    $VERBOSE
  end
end

Errors

You should always be expecting errors from – and in, but that’s a different story – your code:

expect ArgumentError do
  Integer('1 + 1')
end

Often, not only the type of the error, but its description, is important to check:

expect StandardError.new('message') do
  raise StandardError.new('message')
end

As with Strings, Regexps can be used to check the error description:

expect StandardError.new(/mess/) do
  raise StandardError.new('message')
end

Queries Through Symbols

Symbols are generally matched against symbols, but as a special case, symbols ending with ? are seen as expectations on the result of query methods on the result of the block, given that the method is of zero arity and that the result isn’t a Symbol itself. Simply expect a symbol ending with ?:

expect :empty? do
  []
end

To expect it’s negation, expect the same symbol beginning with not_:

expect :not_nil? do
  [1, 2, 3]
end

This is the same as

expect true do
  [].empty?
end

and

expect false do
  [1, 2, 3].empty?
end

but provides much clearer failure messages. It also makes the expectation’s intent a lot clearer.

Queries By Proxy

There’s also a way to make the expectations of query methods explicit by invoking methods on the result of the block. For example, to check that the even elements of the Array [1, 2, 3] include 1 you could write

expect result.to.include? 1 do
  [1, 2, 3].reject{ |e| e.even? }
end

You could likewise check that the result doesn’t include 2:

expect result.not.to.include? 2 do
  [1, 2, 3].reject{ |e| e.even? }
end

This is the same as (and executes a little bit slower than) writing

expect false do
  [1, 2, 3].reject{ |e| e.even? }.include? 2
end

but provides much clearer failure messages. Given that these two last examples would fail, you’d get a message saying “[1, 2, 3]#include?(2)” instead of the terser “true≠false”. It also clearly separates the actual expectation from the set-up.

The keyword for this kind of expectations is result. This may be followed by any of the methods

• #not

• #to

• #be

• #have

or any other method you will want to call on the result. The methods #to, #be, and #have do nothing except improve readability. The #not method inverts the expectation.

Literal Literals

If you need to literally check against any of the types of objects otherwise treated specially, that is, any instances of

• Module

• Range

• Regexp

• Exception

• Symbol, given that it ends with ?

you can do so by wrapping it in literal(…):

expect literal(:empty?) do
  :empty?
end

You almost never need to do this, as, for all but symbols, instances will match accordingly as well.

Expectations on Behavior

We expect our objects to be on their best behavior. Lookout allows you to make sure that they are.

Reception expectations let us verify that a method is called in the way that we expect it to be:

expect mock.to.receive.to_str(without_arguments){ '123' } do |o|
  o.to_str
end

Here, #mock creates a mock object, an object that doesn’t respond to anything unless you tell it to. We tell it to expect to receive a call to #to_str without arguments and have #to_str return '123' when called. The mock object is then passed in to the block so that the expectations placed upon it can be fulfilled.

Sometimes we only want to make sure that a method is called in the way that we expect it to be, but we don’t care if any other methods are called on the object. A stub object, created with #stub, expects any method and returns a stub object that, again, expects any method, and thus fits the bill.

expect stub.to.receive.to_str(without_arguments){ '123' } do |o|
  o.to_str if o.convertable?
end

You don’t have to use a mock object to verify that a method is called:

expect Object.to.receive.name do
  Object.name
end

As you have figured out by now, the expected method call is set up by calling #receive after #to. #Receive is followed by a call to the method to expect with any expected arguments. The body of the expected method can be given as the block to the method. Finally, an expected invocation count may follow the method. Let’s look at this formal specification in more detail.

The expected method arguments may be given in a variety of ways. Let’s introduce them by giving some examples:

expect mock.to.receive.a do |m|
  m.a
end

Here, the method #a must be called with any number of arguments. It may be called any number of times, but it must be called at least once.

If a method must receive exactly one argument, you can use Object, as the same matching rules apply for arguments as they do for state expectations:

expect mock.to.receive.a(Object) do |m|
  m.a 0
end

If a method must receive a specific argument, you can use that argument:

expect mock.to.receive.a(1..2) do |m|
  m.a 1
end

Again, the same matching rules apply for arguments as they do for state expectations, so the previous example expects a call to #a with 1, 2, or the Range 1..2 as an argument on m.

If a method must be invoked without any arguments you can use without_arguments:

expect mock.to.receive.a(without_arguments) do |m|
  m.a
end

You can of course use both Object and actual arguments:

expect mock.to.receive.a(Object, 2, Object) do |m|
  m.a nil, 2, '3'
end

The body of the expected method may be given as the block. Here, calling #a on m will give the result 1:

expect mock.to.receive.a{ 1 } do |m|
  raise 'not 1' unless m.a == 1
end

If no body has been given, the result will be a stub object.

To take a block, grab a block parameter and #call it:

expect mock.to.receive.a{ |&b| b.call(1) } do |m|
  j = 0
  m.a{ |i| j = i }
  raise 'not 1' unless j == 1
end

To simulate an #each-like method, #call the block several times.

Invocation count expectations can be set if the default expectation of “at least once” isn’t good enough. The following expectations are possible

• #at_most_once

• #once

• #at_least_once

• #twice

And, for a given N,

• #at_most(N)

• #exactly(N)

• #at_least(N)

Utilities: Stubs

Method stubs are another useful thing to have in a unit testing framework. Sometimes you need to override a method that does something a test shouldn’t do, like access and alter bank accounts. We can override – stub out – a method by using the #stub method. Let’s assume that we have an Account class that has two methods, #slips and #total. #Slips retrieves the bank slips that keep track of your deposits to the Account from a database. #Total sums the #slips. In the following test we want to make sure that #total does what it should do without accessing the database. We therefore stub out #slips and make it return something that we can easily control.

expect 6 do |m|
  stub(Class.new{
         def slips
           raise 'database not available'
         end

         def total
           slips.reduce(0){ |m, n| m.to_i + n.to_i }
         end
       }.new, :slips => [1, 2, 3]){ |account| account.total }
end

To make it easy to create objects with a set of stubbed methods there’s also a convenience method:

expect 3 do
  s = stub(:a => 1, :b => 2)
  s.a + s.b
end

This short-hand notation can also be used for the expected value:

expect stub(:a => 1, :b => 2).to.receive.a do |o|
  o.a + o.b
end

and also works for mock objects:

expect mock(:a => 2, :b => 2).to.receive.a do |o|
  o.a + o.b
end

Blocks are also allowed when defining stub methods:

expect 3 do
  s = stub(:a => proc{ |a, b| a + b })
  s.a(1, 2)
end

If need be, we can stub out a specific method on an object:

expect 'def' do
  stub('abc', :to_str => 'def'){ |a| a.to_str }
end

The stub is active during the execution of the block.

Overriding Constants

Sometimes you need to override the value of a constant during the execution of some code. Use #with_const to do just that:

expect 'hello' do
  with_const 'A::B::C', 'hello' do
    A::B::C
  end
end

Here, the constant A::B::C is set to 'hello' during the execution of the block. None of the constants A, B, and C need to exist for this to work. If a constant doesn’t exist it’s created and set to a new, empty, Module. The value of A::B::C, if any, is restored after the block returns and any constants that didn’t previously exist are removed.

Overriding Environment Variables

Another thing you often need to control in your tests is the value of environment variables. Depending on such global values is, of course, not a good practice, but is often unavoidable when working with external libraries. #With_env allows you to override the value of environment variables during the execution of a block by giving it a Hash of key/value pairs where the key is the name of the environment variable and the value is the value that it should have during the execution of that block:

expect 'hello' do
  with_env 'INTRO' => 'hello' do
    ENV['INTRO']
  end
end

Any overridden values are restored and any keys that weren’t previously a part of the environment are removed when the block returns.

Overriding Globals

You may also want to override the value of a global temporarily:

expect 'hello' do
  with_global :$stdout, StringIO.new do
    print 'hello'
    $stdout.string
  end
end

You thus provide the name of the global and a value that it should take during the execution of a block of code. The block gets passed the overridden value, should you need it:

expect true do
  with_global :$stdout, StringIO.new do |overridden|
    $stdout != overridden
  end
end

3.0.0

The xml expectation has been dropped. It wasn’t documented, didn’t suit very many use cases, and can be better implemented by an external library.

The arg argument matcher for mock method arguments has been removed, as it didn’t provide any benefit over using Object.

The #yield and #each methods on stub and mock methods have been removed. They were slightly weird and their use case can be implemented using block parameters instead.

The stub method inside expect blocks now stubs out the methods during the execution of a provided block instead of during the execution of the whole except block.

When a mock method is called too many times, this is reported immediately, with a full backtrace. This makes it easier to pin down what’s wrong with the code.

Query expectations were added.

Explicit query expectations were added.

Fluent boolean expectations, for example, expect nil.to.be.nil? have been replaced by query expectations (expect :nil? do nil end) and explicit query expectations (expect result.to.be.nil? do nil end). This was done to discourage creating objects as the expected value and creating objects that change during the course of the test.

The literal expectation was added.

Equality (#==) is now checked before “caseity” (#===) for modules, ranges, and regular expressions to match the documentation.