Forum: Ruby Forcing some code to run at the end of tests

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-13 23:45
(Received via mailing list)
I'm playing with some test scripts, and I cannot for the life of me
ensure that a block of code is run after every test is run.  I can
think of some ugly ways to do it.. but is there an elegant way which I
missed?
2ffac40f8a985a2b2749244b8a1c4161?d=identicon&s=25 Mike Stok (Guest)
on 2006-05-14 00:03
(Received via mailing list)
On 13-May-06, at 5:44 PM, Sy Ali wrote:

> I'm playing with some test scripts, and I cannot for the life of me
> ensure that a block of code is run after every test is run.  I can
> think of some ugly ways to do it.. but is there an elegant way which I
> missed?

Does every test mean every test case?  If so you might look at
Test::Unit::TestCase's teardown.

Mike

--

Mike Stok <mike@stok.ca>
http://www.stok.ca/~mike/

The "`Stok' disclaimers" apply.
9358cc96c46055cd68d4a76a9aefe026?d=identicon&s=25 Daniel Harple (Guest)
on 2006-05-14 00:28
(Received via mailing list)
On May 13, 2006, at 11:44 PM, Sy Ali wrote:

> I'm playing with some test scripts, and I cannot for the life of me
> ensure that a block of code is run after every test is run.  I can
> think of some ugly ways to do it.. but is there an elegant way which I
> missed?

Use the teardown method:

def teardown
   # ...
end

This is mentioned in the docs: http://www.ruby-doc.org/stdlib/libdoc/
test/unit/rdoc/classes/Test/Unit.html

-- Daniel
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 00:28
(Received via mailing list)
On 5/13/06, Mike Stok <mike@stok.ca> wrote:
>
> On 13-May-06, at 5:44 PM, Sy Ali wrote:
>
> > I'm playing with some test scripts, and I cannot for the life of me
> > ensure that a block of code is run after every test is run.  I can
> > think of some ugly ways to do it.. but is there an elegant way which I
> > missed?
>
> Does every test mean every test case?  If so you might look at
> Test::Unit::TestCase's teardown.

No, not teardown.. I want to have some code executed after all testing
has concluded.

You'd think it'd be a matter of running it all at the end of the .rb
file, but this is not true.. everything is run and _then_ the test
cases are run.

I suppose I could wrap the entire test in another ruby file.. it just
seems strange to need to do this.
37a3c73ffbf864e4b28f7f2384ee12ce?d=identicon&s=25 Timothy Hunter (tim-hunter)
on 2006-05-14 00:40
(Received via mailing list)
On May 13, 2006, at 6:27 PM, Sy Ali wrote:

>> Does every test mean every test case?  If so you might look at
> seems strange to need to do this.
Use an END block.
2ffac40f8a985a2b2749244b8a1c4161?d=identicon&s=25 Mike Stok (Guest)
on 2006-05-14 00:40
(Received via mailing list)
On 13-May-06, at 6:27 PM, Sy Ali wrote:

>> Does every test mean every test case?  If so you might look at
> seems strange to need to do this.
Have you ever tried code like this:

#!/usr/bin/env ruby

foo = nil
END { puts "end #{foo}" }
puts "regular code"
foo = 'bar'
BEGIN { puts "begin" }

Maybe an END block can help you (but be careful of bindings and
visibility...)

Mike


--

Mike Stok <mike@stok.ca>
http://www.stok.ca/~mike/

The "`Stok' disclaimers" apply.
37a3c73ffbf864e4b28f7f2384ee12ce?d=identicon&s=25 Timothy Hunter (tim-hunter)
on 2006-05-14 00:46
(Received via mailing list)
On May 13, 2006, at 5:44 PM, Sy Ali wrote:

> I'm playing with some test scripts, and I cannot for the life of me
> ensure that a block of code is run after every test is run.  I can
> think of some ugly ways to do it.. but is there an elegant way which I
> missed?

Are you using Test::Unit? Look at the teardown method.
Ced5fff44ff8929fc974012ea108b284?d=identicon&s=25 Sergey Volkov (rf-vsv)
on 2006-05-14 01:41
(Received via mailing list)
you can use 'ensure' inside begin/def  block:
#
<test preparation code>
begin
    <execute tests>
ensure
    <code executed after all testing>
end
#
----- Original Message -----
From: "Sy Ali" <sy1234@gmail.com>
To: "ruby-talk ML" <ruby-talk@ruby-lang.org>
Sent: Saturday, May 13, 2006 6:27 PM
Subject: Re: Forcing some code to run at the end of tests


On 5/13/06, Mike Stok <mike@stok.ca> wrote:
>
> On 13-May-06, at 5:44 PM, Sy Ali wrote:
>
> > I'm playing with some test scripts, and I cannot for the life of me
> > ensure that a block of code is run after every test is run.  I can
> > think of some ugly ways to do it.. but is there an elegant way which I
> > missed?
>
> Does every test mean every test case?  If so you might look at
> Test::Unit::TestCase's teardown.

No, not teardown.. I want to have some code executed after all testing
has concluded.

You'd think it'd be a matter of running it all at the end of the .rb
file, but this is not true.. everything is run and _then_ the test
cases are run.

I suppose I could wrap the entire test in another ruby file.. it just
seems strange to need to do this.
9358cc96c46055cd68d4a76a9aefe026?d=identicon&s=25 Daniel Harple (Guest)
on 2006-05-14 02:11
(Received via mailing list)
On May 14, 2006, at 12:27 AM, Sy Ali wrote:

> No, not teardown.. I want to have some code executed after all testing
> has concluded.
>
> You'd think it'd be a matter of running it all at the end of the .rb
> file, but this is not true.. everything is run and _then_ the test
> cases are run.
>
> I suppose I could wrap the entire test in another ruby file.. it just
> seems strange to need to do this.

You can setup your test runner manually:

require 'test/unit'
require 'test/unit/ui/console/testrunner'

class TestBlah < Test::Unit::TestCase
   def test_asdf
   end
end

puts "start"
Test::Unit::UI::Console::TestRunner.run(TestBlah)
puts "finish"

You could do the same with a suite. See the [Test::Unit docs][1] on
how to create a test suite manually.

If you are using the rake test task, then you could something like (I
didn't test this out):

class MyTestTask < Rake::TestTask
   def define
     super()
     # ... code you need here
   end
end

Why exactly do you need this code to be run at the end of your test?

[1]: http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/

-- Daniel
9358cc96c46055cd68d4a76a9aefe026?d=identicon&s=25 Daniel Harple (Guest)
on 2006-05-14 03:12
(Received via mailing list)
On May 14, 2006, at 2:09 AM, Daniel Harple wrote:

> If you are using the rake test task, then you could something like
> (I didn't test this out):
>
> class MyTestTask < Rake::TestTask
>   def define
>     super()
>     # ... code you need here
>   end
> end

or this (much simpler):

Rake::TestTask.new(:real_test)
task :test => [:real_test] do
   # code here
end

-- Daniel
8d775a4f841200707929b36728efcccf?d=identicon&s=25 Suraj N. Kurapati (Guest)
on 2006-05-14 03:33
(Received via mailing list)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sy Ali wrote:
>
> I suppose I could wrap the entire test in another ruby file.. it just
> seems strange to need to do this.
>

Try Kernel#at_exit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEZoigmV9O7RYnKMcRAnGqAKCzdsd8ZRGFFylu8PLWePZ/O7JwlQCfd1it
EZm2Css1MI1cLunv3M3kOCc=
=Mh2m
-----END PGP SIGNATURE-----
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 12:16
(Received via mailing list)
Thanks for the ideas everyone..

I did think of using an end block or ensure, but these seemed unclean
to me.  I wondered if there was a feature similar to setup/teardown
for doing stuff on exit.

Doing the test stuff manually to force the order tests and other code
is executed in.. I tried and failed at.. I knew how to run my tests
manually but they were being pulled out from the actual scoring.
Those examples help a lot.  I'll need to keep these in mind if ever I
need to run multiple tests in a specific order (hopefully never!)

I think by far the easiest solution is Kernel#at_exit .. it totally
slipped my mind!
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 12:37
(Received via mailing list)
On 5/14/06, Sy Ali <sy1234@gmail.com> wrote:
> I think by far the easiest solution is Kernel#at_exit .. it totally
> slipped my mind!

Scratch that.  at_exit doesn't work either.

If one of my tests sets a global variable or writes information in a
file.. at_exit will *still* not see the global variable or data..
because the entire tc_name.rb script exits, runs at_exit, and *then*
the tests are run.  Wierd!

I'll explore forcing that test to be run in a more manual way.  Some
examples were given in this thread.. I'll pick them apart and try them
out.
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 13:17
(Received via mailing list)
On 5/13/06, Mike Stok <mike@stok.ca> wrote:
> Maybe an END block can help you (but be careful of bindings and
> visibility...)

Hey that's neat.

But it works the same way that at_exit does.. and so my tests are run
_after_ it.
*boggle*

Continuing to test.  =)
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 13:32
(Received via mailing list)
I played with 'ensure', but it wasn't the answer..  =)


On 5/13/06, Daniel Harple <dharple@generalconsumption.org> wrote:
> You can setup your test runner manually:
<snip>
> You could do the same with a suite. See the [Test::Unit docs][1] on
> how to create a test suite manually.
<snip>
> [1]: http://www.ruby-doc.org/stdlib/libdoc/test/unit/rdoc/

I'm looking into this next.  I'm not using Rake, so I'll look at the
docs on test unit to do things more manually.


> Why exactly do you need this code to be run at the end of your test?

I'm doing this because I have some tests which will be specific for a
platform, and I want to generate a report to state which tests were
skipped.

Is there an easy way for me to abort a test?  (i.e. to exit the test
method cleanly?)
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2006-05-14 18:19
(Received via mailing list)
On May 14, 2006, at 7:29 AM, Sy Ali wrote:

>> Why exactly do you need this code to be run at the end of your test?
>
> I'm doing this because I have some tests which will be specific for a
> platform, and I want to generate a report to state which tests were
> skipped.
>
> Is there an easy way for me to abort a test?  (i.e. to exit the test
> method cleanly?)
>

Aha, now this definitely seems like something that should be there if
its not already.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-14 19:17
(Received via mailing list)
On Sun, 14 May 2006, Sy Ali wrote:

>
> Is there an easy way for me to abort a test?  (i.e. to exit the test
> method cleanly?)


     harp:~ > cat a.rb
     require 'test/unit'
     class FooBarTest < Test::Unit::TestCase
       def test_000
         assert true
       end
       def test_001
         assert true
         abort_test!
         assert false
       end


       def abort_test!
         throw 'abort_test!'
       end
       def self.abortable m
         m, m2 = "#{ m }", "__#{ m }__"
         alias_method m2, m
         define_method(m){|*a| catch('abort_test!'){ send(m2,*a) } }
       end
       instance_methods.each{|m| abortable m if m =~ %r/^test/}
     end


     harp:~ > ruby a.rb
     Loaded suite a
     Started
     ..
     Finished in 0.000518 seconds.

     2 tests, 2 assertions, 0 failures, 0 errors

regards.

-a
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 20:49
(Received via mailing list)
On 5/14/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> On Sun, 14 May 2006, Sy Ali wrote:
> > Is there an easy way for me to abort a test?  (i.e. to exit the test
> > method cleanly?)
>
>      harp:~ > cat a.rb
<snip>
> regards.

Awesome!  That's just what I was looking for (for that particular
problem).  It's strange that the feature isn't there already.

Now I'm going to play with setting the order of my tests to get a
block of code to execute last.
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-14 21:11
(Received via mailing list)
On 5/13/06, Daniel Harple <dharple@generalconsumption.org> wrote:
> You can setup your test runner manually:
<example snipped>

Thank you.  This was just the solution I needed.  It was easy to get
working too.  =)
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-14 23:45
(Received via mailing list)
On Mon, 15 May 2006, Sy Ali wrote:

> problem).  It's strange that the feature isn't there already.
>
> Now I'm going to play with setting the order of my tests to get a
> block of code to execute last.

i'ts simple : they are run in alphabetical order. so, if you name them

   test_000
   test_001
   test_002
   ...

they are run in 'order'.


-a
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-15 00:01
(Received via mailing list)
On 5/14/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> i'ts simple : they are run in alphabetical order. so, if you name them
>
>    test_000
>    test_001
>    test_002
>    ...
>
> they are run in 'order'.


I wouldn't want to put my non-test code in a test.. it seems wierd.

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.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-15 05:08
(Received via mailing list)
On Mon, 15 May 2006, Sy Ali wrote:

>
> I wouldn't want to put my non-test code in a test.. it seems wierd.

well, if you have non-test code you can do whatever you like to order it


   class FooBarTest < Test::Unit::TestCase
     def self.call_it
     end

     p 'do_this'
     p 'do_that'

     call_it
   end

etc.

> 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.

http://groups.google.com/group/comp.lang.ruby/tree...

where did you hear it might be removed in the future?

regards.

-a
A402df36168b81b31c17adcbb5ae8cf4?d=identicon&s=25 Pistos Christou (pistos)
on 2006-05-15 18:38
Sy Ali wrote:
> On 5/13/06, Daniel Harple <dharple@generalconsumption.org> wrote:
>> You can setup your test runner manually:
> <example snipped>
>
> 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?

Pistos
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-15 19:23
(Received via mailing list)
yn Tue, 16 May 2006, Pistos Christou wrote:

> 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?
>
> Pistos

what's wrong with BEGIN and END blocks?

-a
A402df36168b81b31c17adcbb5ae8cf4?d=identicon&s=25 Pistos Christou (pistos)
on 2006-05-15 20:20
unknown wrote:
>> 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?

Where exactly do they go?  In the Rakefile?

Pistos
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-16 01:10
(Received via mailing list)
On 5/14/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> 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.  =)
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-16 01:10
(Received via mailing list)
On 5/15/06, Pistos Christou <jesusrubsyou.5.pistos@geoshell.com> wrote:
> 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.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-16 02:08
(Received via mailing list)
On Tue, 16 May 2006, Sy Ali wrote:

> On 5/14/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
>> 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.

   1 tests, 1 assertions, 0 failures, 0 errors
   ======== END ========


>> 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.  =)

hmm. well the link i sent, although a bit old, was from the test/unit
maintainer, so i think that's probably right for now.

cheers.

-a
E88f6101501d3ca871ad838f85b6378a?d=identicon&s=25 Vidar Larsen (Guest)
on 2006-05-16 09:35
(Received via mailing list)
Den 16. mai. 2006 kl. 02:07 skrev ara.t.howard@noaa.gov:

>
>     def test_a() assert true end
>   1 tests, 1 assertions, 0 failures, 0 errors
>   ======== END ========
>

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>


/Vidar
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-16 16:04
(Received via mailing list)
> >> 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.

> > On 5/14/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> >> where did you hear it might be removed in the future?

> On Tue, 16 May 2006, Sy Ali wrote:
> > I wish I had a source for this, but I don't.  I'm just told it by
> > people who know better than me.  =)

On 5/15/06, ara.t.howard@noaa.gov <ara.t.howard@noaa.gov> wrote:
> hmm. well the link i sent, although a bit old, was from the test/unit
> maintainer, so i think that's probably right for now.

Ok, so instead of basing my preference on a rumour I'll just base my
preference on avoiding the requirement to run tests in any particular
order.  =)

Tests should all be independant of oneanother, otherwise you can't run
just one arbitrary test when you want.
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-16 16:07
(Received via mailing list)
On 5/16/06, Vidar Larsen <vi_larsen@yahoo.no> wrote:

> then the result will be:
>
> ======== BEGIN ========
> ======== END ========
> Loaded suite a
> Started
> .
> Finished in 0.001859 seconds.
>
> 1 tests, 1 assertions, 0 failures, 0 errors

Yes, this is exactly what I was doing.  Curious.
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-16 16:20
(Received via mailing list)
On Tue, 16 May 2006, Vidar Larsen wrote:

> 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.

     harp:~ > cat a.rb
     BEGIN{ p Queue rescue warn $! }

     END{ p Queue }

     require 'thread'
     raise



     harp:~ > ruby a.rb
     uninitialized constant Queue
     a.rb:4: unhandled exception
     Queue

if you move the BEGIN/END blocks to the end of this script you will only
get

     uninitialized constant Queue
     a.rb:4: unhandled exception

which is very counter-intuitive.  in any case it's good pratice to put
BEGIN/END blocks up front imho.

cheers.


-a
Cb48ca5059faf7409a5ab3745a964696?d=identicon&s=25 unknown (Guest)
on 2006-05-16 16:48
(Received via mailing list)
On Tue, 16 May 2006, Sy Ali wrote:

>> end
>> 1 tests, 1 assertions, 0 failures, 0 errors
>
> Yes, this is exactly what I was doing.  Curious.

it's because test/unit registers it's own blocks too.

-a
A402df36168b81b31c17adcbb5ae8cf4?d=identicon&s=25 Pistos Christou (pistos)
on 2006-05-16 18:32
Sy Ali wrote:
>> 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.

Thanks for the TestRunner tip though.

Pistos
68db3bafb0a990bf605c4cf62bf85db0?d=identicon&s=25 bpettichord@gmail.com (Guest)
on 2006-05-17 07:51
(Received via mailing list)
>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.

That was probably me who said that. I was wrong. They are alphabetical.

Check the wtr-general list, however, for a patch i released that makes
them run in the order you define them in.

Bret
68db3bafb0a990bf605c4cf62bf85db0?d=identicon&s=25 bpettichord@gmail.com (Guest)
on 2006-05-17 07:54
(Received via mailing list)
There is a good reason for this.

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.
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-05-17 21:09
(Received via mailing list)
On 5/17/06, bpettichord@gmail.com <bpettichord@gmail.com> wrote:
> 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.

Neat.
0ec3bf94bce07e41ebe0df6c7edb9521?d=identicon&s=25 Brian Cowdery (bcowdery)
on 2006-06-15 20:29
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.

All you really need to to is extend Test::Unit::TestCase and
programaticly add functionality for a startup() method (to run before
all testcases) and a close() method to run after everything.

In the class below i've overloaded #run to check if a startup methods
been run, and if not launch it before running anything. I've also made
use of the default_test (which curiously always runs after? - this might
be changed later on so i won't count in it working forever), to launch
the close method.

require 'test/unit/assertions'
require 'test/unit/failure'
require 'test/unit/error'
require 'test/unit/assertionfailederror'
require 'test/unit/testcase'

module Test
  module Unit
    class BetterTestCase < TestCase

      # startup flag
      @@startup_flag = true

      # Overloaded from Test::Unit::TestCase
      def run(result)
        if(@@startup_flag)
          begin
            startup
          rescue
            #ignore
          ensure
            @@startup_flag = false
          end
        end

        yield(STARTED, name)
        @_result = result
        begin
          setup
          __send__(@method_name)
        rescue AssertionFailedError => e
          add_failure(e.message, e.backtrace)
        rescue StandardError, ScriptError
          add_error($!)
        ensure
          begin
            teardown
          rescue AssertionFailedError => e
            add_failure(e.message, e.backtrace)
          rescue StandardError, ScriptError
            add_error($!)
          end
        end
        result.add_run
        yield(FINISHED, name)
      end

      # Called once before any test method runs. Can be used to
      # setup script-wide variables and conditions.
      def startup
      end

      # Called once after all test methods have ran. Can be used to
      # cleaup the environment after completion of the test methods.
      def close
      end

      #overload default_test, actualy runs last?
      def default_test
        begin
          close
        rescue
          #noop
        end
      end
    end
  end
end


After all this you can build your Test::Unit::TestCases by extending
that instead, and using startup and close the same way you would use
setup & teardown. handy eh?

example test case with startup and close methods:




require 'test/unit'
require 'better_test_case'

class ExampleTest < BetterTestCase

 def startup
    #do somthing once before any tests are run
 end

 def close
    #do somthing after all tests are run
 end

 def test_0010_somthing
    #test somthing...
 end

end
316017672dfe1c4e8e22843348ee32d4?d=identicon&s=25 Sy Ali (Guest)
on 2006-06-19 23:07
(Received via mailing list)
On 6/15/06, Brian Cowdery <bcowdery@gmail.com> wrote:
> 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.
24c6e4ed08f7a4bf9cfb7edc2dbd14b8?d=identicon&s=25 Patrick Spence (pkspence)
on 2006-06-30 20:03
Brian Cowdery wrote:

<snip>

> class ExampleTest < BetterTestCase #<< error here >>
>
>  def startup
>     #do somthing once before any tests are run
>  end
>
>  def close
>     #do somthing after all tests are run
>  end
>
>  def test_0010_somthing
>     #test somthing...
>  end
>
> end

When I try to run this script, I'm getting a "uninitialized constant
BetterTestCase (NameError)" error on line indicated above. Ideas anyone?
5c4e57ad9f066e56297a60b4a1daa1d3?d=identicon&s=25 Alexandru Popescu (Guest)
on 2006-07-01 03:13
(Received via mailing list)
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.

./alex
--
.w( the_mindstorm )p.
---
Co-founder TestNG
This topic is locked and can not be replied to.