I'm trying to set up an SUnit test that uses a TestResource. The "resource" is a bunch of traits that need to be created one time at the start of the test run and deleted at the end of the test run, and are looked at but not modified by any of the tests (so they don't need to be cleaned up between tests; it would take far too long).
The trouble I'm having is that SUnit appears to call setUp on the resource, but never calls tearDown. Are there any SUnit hackers out there that can tell me whether resources in SUnit are known to be broken (in which case maybe I could help fix them) or whether I'm just doing things the wrong way? I wasn't able to find any useful documentation on the right way to do it, so I've been figuring it out just by reading the code.
Thanks, Peter
Hi Peter,
Do you use test suites?
as far as I understand it, you would want to use test suites to handle test resources. There is
TestSuite >> run (...) [self run: result] sunitEnsure: [self resources do: [:each | each reset]]. ^result
which should do the cleanup at the end.
Stef wrote a nice intro on SUnit on: http://www.iam.unibe.ch/~ducasse/Programmez/OnTheWeb/Eng-Art8-SUnit- V1.pdf
As far as I can tell, there is no test/example which clarifies that behavior, so it would be great if you could enhance the SUnit-Tests accordingly.
Hope this helps,
Markus On Jul 29, 2004, at 2:18, Peter Keeler wrote:
I'm trying to set up an SUnit test that uses a TestResource. The "resource" is a bunch of traits that need to be created one time at the start of the test run and deleted at the end of the test run, and are looked at but not modified by any of the tests (so they don't need to be cleaned up between tests; it would take far too long).
The trouble I'm having is that SUnit appears to call setUp on the resource, but never calls tearDown. Are there any SUnit hackers out there that can tell me whether resources in SUnit are known to be broken (in which case maybe I could help fix them) or whether I'm just doing things the wrong way? I wasn't able to find any useful documentation on the right way to do it, so I've been figuring it out just by reading the code.
Thanks, Peter
Markus Gaelli gaelli@emergent.de wrote:
Do you use test suites?
Surely the tearDown should happen automatically if you use the standard test runner?
-Lex
On Aug 3, 2004, at 20:48, lex@cc.gatech.edu wrote:
Markus Gaelli gaelli@emergent.de wrote:
Do you use test suites?
Surely the tearDown should happen automatically if you use the standard test runner?
It does. But what Peter wants is to _keep_ the resource after a test has run and only reset the resource after all the tests of a certain suite have run. I wanted to suggest him to use TestSuites then, as they sent "reset" to the resources after all their tests have run. Hope that helps,
Markus
Hi peter
Resources are normally set before any test run and teardown after all the test run if I remember correctly. In the tutorial I show how you can add sharedSetUp Test that do not execute setup for all the tests of a test suite but that executes it for each test suite. I really needed that and ressources were not the answer.
Stef
On 29 juil. 04, at 02:18, Peter Keeler wrote:
I'm trying to set up an SUnit test that uses a TestResource. The "resource" is a bunch of traits that need to be created one time at the start of the test run and deleted at the end of the test run, and are looked at but not modified by any of the tests (so they don't need to be cleaned up between tests; it would take far too long).
The trouble I'm having is that SUnit appears to call setUp on the resource, but never calls tearDown. Are there any SUnit hackers out there that can tell me whether resources in SUnit are known to be broken (in which case maybe I could help fix them) or whether I'm just doing things the wrong way? I wasn't able to find any useful documentation on the right way to do it, so I've been figuring it out just by reading the code.
Thanks, Peter
At 10:20 +0200 2004.8.4, stéphane ducasse wrote:
Resources are normally set before any test run and teardown after all the test run if I remember correctly.
That is indeed what you imply in the tutorial;. But as far as we can see, it is not what the code does. It calls "reset", not "tearDown".
In the tutorial I show how you can add sharedSetUp Test that do not execute setup for all the tests of a test suite but that executes it for each test suite. I really needed that and ressources were not the answer.
Are you referring to the TestSuite>>areAllResourcesAvailable" stuff? We were confused because this is not what our version of SUnit does, and assumed that the documentation was out of date, not that this was a an enhancement.
I don't see how what you describe above for "sharedSetUp" is different from Resources, if they worked correctly.
Andrew
On 4 août 04, at 20:00, Andrew P. Black wrote:
At 10:20 +0200 2004.8.4, stéphane ducasse wrote:
Resources are normally set before any test run and teardown after all the test run if I remember correctly.
That is indeed what you imply in the tutorial;. But as far as we can see, it is not what the code does. It calls "reset", not "tearDown".
May be I refer to another version because SUnit releases are the mess.
In the tutorial I show how you can add sharedSetUp Test that do not execute setup for all the tests of a test suite but that executes it for each test suite. I really needed that and ressources were not the answer.
Are you referring to the TestSuite>>areAllResourcesAvailable" stuff?
I do not remember. I wrote that so long ago and my code refers to VW SUnit version.
We were confused because this is not what our version of SUnit does, and assumed that the documentation was out of date, not that this was a an enhancement.
I don't see how what you describe above for "sharedSetUp" is different from Resources, if they worked correctly.
A resources is initialized before **any** test runs, so one of your testsuite may invalidate the resource that is need in a certain state by another test suite. I discussed a lot with joseph about that and I will show why we need that with alan knight at ESUG. In moose for example, each test suite build a different model of a program, which is then accessed using a singleton, so the resources could not work there since testOne would run on a model that is not adequate (may be installed by the resources associated with testTwo).
Andrew
squeak-dev@lists.squeakfoundation.org
-
Andrew P. Black -
lex＠cc.gatech.edu -
Markus Gaelli -
Peter Keeler -
stéphane ducasse