Stay on Target

Flexible Argument Matching with Mocha

If your Ruby unit tests are failing because you change the signature of a method and all your mock expectations fail, you might have a case of Overspecified Software.  To fix this problem, make your test require only the parameters that are significant.  To quote Gerard Meszaros, "If a value is not important to a test, it's important that it not be in the test."

For example, imagine you had a test which took an options Hash as a parameter.  You might have an expectation like this:

processor.expects(:order).with(:payment => :credit_card, :delivery => :express, :group => :separate)

Unless your test is verifying that all of these parameters are set correctly, it might be better to change your tests so that each test verifies only the parameters that are important.  In this post, I'll describe how to do this with Mocha, but Flex Mock also provides similar features.

Mocha provides a flexible syntax to match parameters of expectations.  For example, if you wanted to check that a given key was present, and ignore the rest of the arguments, you could say:

processor.expects(:order).with(has_key(:payment))

If you are interested in both the key and value, you could use has_entry, or the alternate has_entries:

processor.expects(:order).with(has_entry(:payment => :credit_card))

If you just wanted to make sure something was NOT present, you can use the Not operation to invert the condition:

processor.expects(:order).with(Not(has_key(:emergency_order)))

Or specify any number of conditions using the any_of condition.  

processor.expects(:order).with(any_of(includes(:delivery), has_key(:shipping)))

Mocha provides many more variations, see the Mocha::ParameterMatchers RDoc for more possibilities.

By combining these parameter matchers, you can make tests that are more expressive about the arguments they care about and avoid unrelated test failures when you make a harmless change to your code.

Text File Processing with Ruby from the Command Line

My colleague David showed me some useful ways to use Ruby for simple text processing from the command line.  I'm blogging about it here to remind myself how it works.  (Thanks for the tip, David!)

The Ruby interpreter can be run in a mode which executes a one-line script against a text file.  You can choose to print the results of the script to standard out or to replace the file.  In this way, Ruby becomes a text processing tool like awk, sed, and grep.

For example, if you've got a file with a list of recipe names (in "recipe_index.txt") and you'd like it to contain only those recipes that have 'banana' in the title, you'd do something like this:

ruby -ni.bak -e 'print if /banana/i' recipe_index.txt

-n feeds every line of input_file into your script, simulating sed's text file processing

-i applies changes to recipe_index.txt in-place, otherwise prints the results to standard out.  If you specify any text after -i, such as "-i.bak", Ruby will first make a copy of your input file and append the extension.  In this example, you'd end up with recipe_index.txt.bak

-e specifies a one-line Ruby script to execute, which prints the line only if it matches the case-insensitive regular express 'banana'

You can also use -p if you want to print out every line of the input file as well as your script's result.  For example, if you wanted to prepend the number of characters in each line to the beginning of the line, you'd say:

ruby -pe 'print $_.size' input_file"

Note the magic variable $_ (dollar sign underscore) which holds the contents of the last line matched by gets().