From: Alex Young <alex@...>
Date: 2008-03-05T02:26:31+09:00
Subject: Aborting unit tests

Hi all,

I've come across this pattern a few times now, and I'm wondering what
the best approach is.  Say I've got a class like this:

class A
  def public_method
    c(b(a))
  end

  private
  def a
    # a stuff
  end

  def b(foo)
    # b stuff
  end

  def c(bar)
    # c stuff
  end
end

Now, in my unit tests, I'm fine with having separate tests for a, b and
c, but I still want to test public_method separately, to ensure that
they're strung together properly.  However, often I can test before
calling it that, for instance, a precondition for b() isn't met, because
of breakage somewhere else in the codebase.  In that case, I don't want
to log public_method as having failed - that's just noise, the fact that
I've got a failure will be logged when the test for b() itself fails.
I'd like to be able to write this in my test:

class ATest < Test::Unit::TestCase
  def test_public_method
    abort_if(!precondition_for_a || 
             !precondition_for_b || 
             !precondition_for_c)
    assert(A.new.public_method, "It didn't work!")
  end
end

I don't want to just wrap the assertion in a conditional, because then
it wouldn't be reported (and a reduced assertion count is too easy to
miss) - but I specifically don't want it reported as a failure.
Ideally, I'd like to see results like this:

$ ruby test/a_test.rb
Loaded suite test/a_test.rb
Started
# failure report here
.........a...a....F
Finished in 0.092032 seconds.

19 tests, 48 assertions, 1 failure, 0 errors, 2 aborts

Has anyone looked at this before?  I can't see anything in the test/unit
docs that look relevant.  Is it worth looking at, or is it just
indicative of some code that needs cleaning up on my part?  If so, how
should it be fixed?  As a concrete example, in Rails controller tests I
often find myself doing something like:

  get :foo
  assert_response :success
  assert_not_nil assigns(:bar)

where if the assert_response :success fails, I know the reason will be
caught in a different test that checks the various error states, but
it's not worth checking assigns(:bar) in this test because it can't
possibly be valid.

Any hints gratefully received...

-- 
Alex