Thank you. This was just the solution I needed. It was easy to get
working too. =)
I have a similar situation: I have to setup and teardown various bits in
a database before and after (respectively) [the combined whole of] ALL
tests. Furthermore, the teardown must occur regardless of whether any
tests pass or fail. I’ve posted to ruby-talk about this a while ago.
My final solution was to just use a wrapper script to call rake, and
then call the teardown code.
Would the above TestRunner solution work for my case, too?
tests. Furthermore, the teardown must occur regardless of whether any
tests pass or fail. I’ve posted to ruby-talk about this a while ago.
My final solution was to just use a wrapper script to call rake, and
then call the teardown code.
Would the above TestRunner solution work for my case, too?
well, if you have non-test code you can do whatever you like to order it
Not really. All the testing code will be run after other code,
nomatter what you do… even using begin/end blocks wouldn’t work for
me. All tests would run afterwards. It was quite wierd. Only the
testrunner stuff ended up working.
On Mon, 15 May 2006, Sy Ali wrote:
As I understand, tests are not guaranteed to run in any order and while this
feature may work right now… it may be removed in the future.
where did you hear it might be removed in the future?
I wish I had a source for this, but I don’t. I’m just told it by
people who know better than me. =)
tests. Furthermore, the teardown must occur regardless of whether any
tests pass or fail. I’ve posted to ruby-talk about this a while ago.
My final solution was to just use a wrapper script to call rake, and
then call the teardown code.
Would the above TestRunner solution work for my case, too?
what’s wrong with BEGIN and END blocks?
I have a similar situation: I have to setup and teardown various bits in
a database before and after (respectively) [the combined whole of] ALL
tests. Furthermore, the teardown must occur regardless of whether any
tests pass or fail. I’ve posted to ruby-talk about this a while ago.
My final solution was to just use a wrapper script to call rake, and
then call the teardown code.
Would the above TestRunner solution work for my case, too?
I think so, yes. TestRunner was simple for me to implement, and it
would guarantee that certain code could run before and after your
tests.
well, if you have non-test code you can do whatever you like to order it
Not really. All the testing code will be run after other code,
nomatter what you do… even using begin/end blocks wouldn’t work for
me. All tests would run afterwards. It was quite wierd. Only the
testrunner stuff ended up working.
can you show us this? it works for me:
harp:~ > cat a.rb
BEGIN{ puts ‘======== BEGIN ========’ }
END{ puts ‘======== END ========’ }
require ‘test/unit’
class ATest < Test::Unit::TestCase
def test_a() assert true end
end
harp:~ > ruby a.rb
======== BEGIN ========
Loaded suite a
Started
.
Finished in 0.000684 seconds.
It looks like the ordering is important. If you do:
require ‘test/unit’
BEGIN{ puts ‘======== BEGIN ========’ }
END{ puts ‘======== END ========’ }
class ATest < Test::Unit::TestCase
def test_a() assert true end
end
then the result will be:
======== BEGIN ========
======== END ========
Loaded suite a
Started
.
Finished in 0.001859 seconds.
1 tests, 1 assertions, 0 failures, 0 errors
The problem is that include/import on top is idiomatic (even
sometimes necessary) in for instance C/C++ and Java, so it seems
natural to carry that over to Ruby. In Ruby, require is an executable
statement, that may have side effects, and thus ordering becomes
significant:
bash$ cat foo.rb
puts “bar”
bash$ irb
irb(main):001:0> require “foo.rb”
bar
=> true
irb(main):002:0>
then the result will be:
The problem is that include/import on top is idiomatic (even sometimes
necessary) in for instance C/C++ and Java, so it seems natural to carry that
over to Ruby.
it’s also idiomatic to have BEGIN/END blocks before require though,
because
BEGIN actually happens before any requires take place and END needs to
occur
(typically) even if require throws an exception.
Would the above TestRunner solution work for my case, too?
I think so, yes. TestRunner was simple for me to implement, and it
would guarantee that certain code could run before and after your
tests.
I think I’ll stick with what I’ve got, because to do TestRunner, I’d
have to write up some test suite wrappers. At the moment, I just have
wads of .rb files for individual test sets, and my Rakefile builds up a
heirarchical set of tasks that lets me run a whole subtree of tests, or
just a specific test (.rb file). My ./run-tests script passes args to
rake, so I can run a specific test or set of tests, but STILL run my
global setup and teardown properly.
test-unit itself puts code in an END block that creates and executes a
test runner if one hasn’t already been created.
And END blocks are executed (at the end) in the REVERSE order than how
they were defined.
Therefore, you have to define your END block before ‘test/unit’ is
loaded. Or create the test runner yourself.
Oh I get it. So it’s not so arcane an issue after all.
For a while I thought I was going mental… things weren’t happening in
the order I was specifying… but it’s just that I didn’t understand
was was going on when I was specifying things the way I was.
I don’t mean to beat a dead horse, but i think i’ve come up with a
viable solution for this that doesn’t involve manualy launching every
test through TestRunner, or stratigicaly placing BEGIN & END blocks.
Hey thanks for the suggestion. My mind isn’t in the right context to
understand it… but when I next revisit the wonderful world of testing
I’ll sit down and learn this.
Not sure I have correctly read this thread and not sure if this helps
(because it is something from JUnit which seems to have some common
ideas): in JUnit you can achieve this behavior by using a TestSetup.
It will allow you to run a method once before all your tests and
another method once after all your tests.
TestNG (http://testng.org), an alternative testing framework for Java
is defining more such places by allowing you to define methods to be
run @Before suite, test, group, class, methods and respectively @After.