Showing hash differences in Ruby tests

Today I was writing some tests for a Rails plugin I'm working on. The test had to compare a hash output by a method with an expected hash.

This is reasonably standard stuff - when assertion_equal failed it printed out the expected and provided data. The problem in my case was that the hashes have about 50 elements, and I only want the difference to be shown in the test output.

I knocked up this function to solve the problem, and included it in my test class:

def assert_hashes_equal(expected, actual, message=nil)
full_message = build_message(message, "Hashes were not equal, diff was:\n.\n", expected.diff(actual))
assert_block(full_message) { expected == actual }
end

So now I get this:

Hashes were not equal, diff was:
<{:plays_in_category=>"2", :dynamic_end=>"MFT", :percent_back=>"100w"}>.

Note that Hash.diff is part of Rails.

Here is what the output looks like in practice:

1) Failure:
test: SelectorImporterTest Concert Selector Parse Song 0 XML should Hashes should be equal. (SelectorImporterTest)
[/test/unit/selector_importer_test.rb:500:in `assert_hashes_equal'
/test/unit/selector_importer_test.rb:368:in `__bind_1271217771_635209'
vendor/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `call'
vendor/gems/thoughtbot-shoulda-2.10.1/lib/shoulda/context.rb:253:in `test: SelectorImporterTest Concert Selector Parse Song 0 XML should Hashes should be equal. ']:
Hashes were not equal, diff was:
<{:mood=>"3"}>.


The New Accessibility Wave

There is a new accessibility imperative.

You may have heard of it: Mobile.

The mobile user experience is fundamentally different from browsing the web on a desktop grade computer and a standard web browser.

Touch devices do not have a keyboard. You cannot control + click. You cannot right click. You cannot click and drag items. (Usually). Non-touch platforms have other challenges. Some do not support certain plugins.

This is going to require a reworking of the way we build websites.

Design and functionality will have to be layered onto content and structure based on the consuming platform.

The techniques to do this already exist. One is progressive enhancement, but at the moment this is more about adding advanced features for desktop-grade browsers.

It needs to go further than this. Websites have to work for everyone without discrimination. If they don't work, the user's experience of your site will be poor, or non-existent.

The reason I say 'new' accessibility wave is that we've already had to make websites for technology that interacts with pages differently from desktop web-browsers: screen readers.

Many ignored this old wave completely, deeming that market as irrelevant, insignificant or uneconomic.

I have bad news for you. That wave is being joined by a new one - tens of millions of people using non-traditional browsing technology, and growing every day.

If you've not thought about it, it is time to think about inclusive websites again. Websites will have to change to support not only screen readers, but mobile, TV and who knows what else.

Open technologies are going to be a big part of this - HTML5, CSS and Javascript.

If you didn't catch the first wave, you have a lot of catching up to do.