A
Alex Young
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 assignsbar)
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 assignsbar) in this test because it can't
possibly be valid.
Any hints gratefully received...
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 assignsbar)
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 assignsbar) in this test because it can't
possibly be valid.
Any hints gratefully received...