I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
end
def test_1
end
def test_2
end
end
then @f gets constructed twice; once for each instance of MyTest.
I’m currently doing this instead:
$f = Foo.new
class MyTest < Test::Unit::TestCase
def setup @f = $f
end
def test_1
end
def test_2
end
end
but surely there has to be a better way! What can I do?
I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
How about
@f ||= Foo.new
···
----- Original Message -----
From: “Paul Brannan” pbrannan@atdesk.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, April 01, 2003 10:35 AM
Subject: sharing objects between tests (revisited?)
I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
How about
@f ||= Foo.new
···
----- Original Message -----
From: “Paul Brannan” pbrannan@atdesk.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, April 01, 2003 10:35 AM
Subject: sharing objects between tests (revisited?)
I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
How about
@f ||= Foo.new
···
----- Original Message -----
From: “Paul Brannan” pbrannan@atdesk.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, April 01, 2003 10:35 AM
Subject: sharing objects between tests (revisited?)
I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
How about
@f ||= Foo.new
···
----- Original Message -----
From: “Paul Brannan” pbrannan@atdesk.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, April 01, 2003 10:35 AM
Subject: sharing objects between tests (revisited?)
I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
end
def test_1
end
def test_2
end
end
then @f gets constructed twice; once for each instance of MyTest.
I’m currently doing this instead:
$f = Foo.new
class MyTest < Test::Unit::TestCase
def setup @f = $f
end
def test_1
end
def test_2
end
end
but surely there has to be a better way! What can I do?
What if you make it a class variable instead?
Something like:
One thing to think about is why that object is expensive to create and
whether it can be done another way. I don’t know anything about the
object you want to test, but I find that if a test is expensive,
that’s because:
The test relies on external resources – database, filesystem,
network – and I might be better off writing a mock object to simulate
those resources.
The test relies on extremely complex setup, and I might be better
off trying to break the object down into smaller parts so I can test
its interactions in isolation.
I find that when testing gets hard, or slow, I do less of it, and then
inevitably I end up regretting that laziness later … So I try to do
the up-front work to make testing fast and easy, so I can always do
lots of it without feeling like I’m forcing myself.
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests.
Sorry for multiple posts, it is my company’s mail server fault :-(.
Switching to my personal mail account.
Gennady.
···
----- Original Message -----
From: “Gennady” gfb@tonesoft.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, April 01, 2003 10:52 AM
Subject: Re: sharing objects between tests (revisited?)
----- Original Message -----
From: “Paul Brannan” pbrannan@atdesk.com
To: “ruby-talk ML” ruby-talk@ruby-lang.org
Sent: Tuesday, April 01, 2003 10:35 AM
Subject: sharing objects between tests (revisited?)
I don’t know if I’ve asked this on this list before or only on irc (I
can’t find an earlier post on the subject, so I appologize if I’m asking
this a second time; I don’t remember the answer).
I have a number of tests that create some object. The tests are not
unit tests, but I am using a unit test framework (RUNIT or Test::Unit)
to write the tests. This object is expensive (time-wise) to create, and
I would like to share the object between my tests. If I write this:
class MyTest < Test::Unit::TestCase
def setup @f = Foo.new
This doesn’t work, since there is a different instance of MyTest for
each test_ method it has. You can verify this by printing id from
the setup() method.
Paul
···
On Wed, Apr 02, 2003 at 03:50:53AM +0900, Gennady wrote:
This test is intended to be an integration test for a system that is
distributed across a network. In order to completely test the system,
the test must make lots of network connections to each of the pieces of
the system, so it can validate that the pieces are correctly
communicating with each other.
I considered trying to test integration between only two pieces at any
given time, but implementing such a test would take a very long time,
since there is one piece of the system that talks to all the other
pieces of the system. Simulating those interactions is a lot of work,
since the communication is with CORBA, and Ruby does not speak CORBA
well.
Paul
···
On Wed, Apr 02, 2003 at 07:30:24PM +0900, Francis Hwang wrote:
Paul,
One thing to think about is why that object is expensive to create and
whether it can be done another way. I don’t know anything about the
object you want to test, but I find that if a test is expensive,
that’s because:
The test relies on external resources – database, filesystem,
network – and I might be better off writing a mock object to simulate
those resources.
The test relies on extremely complex setup, and I might be better
off trying to break the object down into smaller parts so I can test
its interactions in isolation.