On our work on gobalto.com, we spend time to have good fixture data for our tests– data that can represent all the important application states that our tests require. As a result, our tests are very dependent on the data. It’s important that someone doesn’t inadvertantly change it in subtle ways. This has led us to write not only asserts at the end of tests, but pre-conditions as well. For example,
inotech = companies(:inotech)
post :edit_services_dialog, :id=>inotech.id,
Although the pre-conditions were introduced to guard against accidentally changing fixture data (or just to figure out what’s going on), we don’t necessarily delete them. They provide stronger tests. And in some ways, leaving in pre-conditions make the code more readable by providing documentation of your assumptions to the readers. The code above would be hard to follow without the clarifying pre-conditions. What do we expect to change and what stays the same?
Unfortunately all these asserts make the tests twice as long. And there’s a subtle readability problem: there’s no relationship between the corresponding pre- and post-conditions. In the example above, you have to scan carefully to see that the three assertions are repeated, but negated (b and c only). The reader must mentally put pieces together. And it’s not DRY. Using local variables doesn’t help much.
I was inspired by a nice little test helper called assert_difference. It takes a string to evaluate and a block to execute. It’s useful for checking on state changes– especially database changes– during a test:
assert_difference('Company.count', -1) do
(Without this method, we rely on a count of all database records, or merely look for specific ones. The former approach leads to brittle tests, and the latter to incomplete assertions.)
A limitation of assert_difference is that it only deals with integers. What if it were generalized? Here goes:
i = true
assert_changes 'i' => false do # read as: i changes to false
i = false
The string passed to assert changes is evaluated in the block context, both before and after the block is run. So this block asserts that i becomes false (and by deduction, starts out as true). It executes asserts on both ends, just like we want.
Of course sometimes you want to be explicit about a state change, so you can specify both the starting and ending values using an array:
o.answer = 'yes'
assert_changes 'o.answer' => ['yes','no'] do
o.answer = 'no'
To handle the original example, you can pass multiple pre/post conditions of arbitrary complexity and they are all evaluated before and after the block is executed:
assert_changes 'post(:a).status' => [:preview, :published],
'comment(:c).status' => [:preview, :deleted] do
Finally, I added support for a :no_change symbol. Now I can re-write my original problem in a clearer form:
'inotech.services.public.include?(categories(:a))' => [true, :no_change],
post :edit_services_dialog, :id=>inotech.id, :service_category_id=>categories(:a).id
For completeness, I added assert_no_changes, with slightly extended parameter possibilities:
i,j = 'hello','hi'
assert_no_changes 'i' do ... # i (before) == i (after)
assert_no_changes 'i'=>'hello' do ... # i == 'hello' before and after
assert_no_changes ['i','j'] do ... # neither i or j change
assert_no_changes 'i'=>'hello','j'=>'hi' do # or be explicit