[Pharo-project] Test Resources
Hi, Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources. My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset. We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this. Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury -- Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print
On 28 February 2013 17:37, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Are you looking for TestResources? frank
Yes. I'm talking about TestResources. And the way it is currently used in SUnit isn't clear to me. On 28 févr. 2013, at 19:41, Frank Shearar wrote:
On 28 February 2013 17:37, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Are you looking for TestResources?
frank
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com>wrote:
Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Hi Mariano, On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See : TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Sorry if I may ask so bluntly, but did you read how TestResource work? Because if I check in a 2.0 image they works as expected and are only initialized once per test. you add the class to MyTestCase >> #resources ^ Array with: MyResources and initialize all the values you need in the resources MyResources >> #setUp super setUp myValue := #foo MyResources >> #myValue ^ myVale then in the test case you access the resources via it's singleton pattern MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Thanx Camillo ! You are right. I tried in a **clean** 1.4 image and I got the behavior I expected initially. I don't know why in our robotic code we have a strange behavior. BTW, we had put a halt in the middle of the SUnit code (I don't remember where exactly), and got a hang, that we could interrupt, but then all we could see was decompiled code. So, we end up just reading the code and we got surprised with the code that does the reset in TestCase>>run. Noury On 1 mars 2013, at 00:00, Camillo Bruni wrote:
Sorry if I may ask so bluntly, but did you read how TestResource work?
Because if I check in a 2.0 image they works as expected and are only initialized once per test.
you add the class to
MyTestCase >> #resources ^ Array with: MyResources
and initialize all the values you need in the resources
MyResources >> #setUp super setUp myValue := #foo
MyResources >> #myValue ^ myVale
then in the test case you access the resources via it's singleton pattern
MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo
and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite
On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury -- Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print
I figured out the origin of the problem. Resources are used based on a default instance (TestResource class>>current). So, in case there are two test suites running in parallel (this our case), one resets the resource used by the other. Although the context of our project is a bit specific, still this sharing is not so clean. I'd rather prefer to have each resource referenced only by the testSuite where it is used. The tests should get access to the resource through some reference to their respective test suite. Noury On 1 mars 2013, at 10:57, Noury Bouraqadi wrote:
Thanx Camillo !
You are right. I tried in a **clean** 1.4 image and I got the behavior I expected initially. I don't know why in our robotic code we have a strange behavior. BTW, we had put a halt in the middle of the SUnit code (I don't remember where exactly), and got a hang, that we could interrupt, but then all we could see was decompiled code. So, we end up just reading the code and we got surprised with the code that does the reset in TestCase>>run.
Noury On 1 mars 2013, at 00:00, Camillo Bruni wrote:
Sorry if I may ask so bluntly, but did you read how TestResource work?
Because if I check in a 2.0 image they works as expected and are only initialized once per test.
you add the class to
MyTestCase >> #resources ^ Array with: MyResources
and initialize all the values you need in the resources
MyResources >> #setUp super setUp myValue := #foo
MyResources >> #myValue ^ myVale
then in the test case you access the resources via it's singleton pattern
MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo
and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite
On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury -- Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite Please consider the environment before you print
Interesting point. We'll think about that for SUnit 5.0. The easiest solution for you is to subclass TestResource & make TestResource>>current to look into some thread-local variable. You may need to fix isAvailable/makeAvailable (depends on version s SUnit you guys have) Cheers, Jan On 01/03/13 10:31, Noury Bouraqadi wrote:
I figured out the origin of the problem. Resources are used based on a default instance (TestResource class>>current). So, in case there are two test suites running in parallel (this our case), one resets the resource used by the other.
Although the context of our project is a bit specific, still this sharing is not so clean. I'd rather prefer to have each resource referenced only by the testSuite where it is used. The tests should get access to the resource through some reference to their respective test suite.
Noury
On 1 mars 2013, at 10:57, Noury Bouraqadi wrote:
Thanx Camillo !
You are right. I tried in a **clean** 1.4 image and I got the behavior I expected initially. I don't know why in our robotic code we have a strange behavior. BTW, we had put a halt in the middle of the SUnit code (I don't remember where exactly), and got a hang, that we could interrupt, but then all we could see was decompiled code. So, we end up just reading the code and we got surprised with the code that does the reset in TestCase>>run.
Noury On 1 mars 2013, at 00:00, Camillo Bruni wrote:
Sorry if I may ask so bluntly, but did you read how TestResource work?
Because if I check in a 2.0 image they works as expected and are only initialized once per test.
you add the class to
MyTestCase >> #resources ^ Array with: MyResources
and initialize all the values you need in the resources
MyResources >> #setUp super setUp myValue := #foo
MyResources >> #myValue ^ myVale
then in the test case you access the resources via it's singleton pattern
MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo
and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite
On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Actually it is the first time I had a look at the TestResources thingy, and I thought exactly about the same critical point ;) On 2013-03-01, at 12:20, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Interesting point. We'll think about that for SUnit 5.0.
The easiest solution for you is to subclass TestResource & make TestResource>>current to look into some thread-local variable. You may need to fix isAvailable/makeAvailable (depends on version s SUnit you guys have)
Cheers, Jan
On 01/03/13 10:31, Noury Bouraqadi wrote:
I figured out the origin of the problem. Resources are used based on a default instance (TestResource class>>current). So, in case there are two test suites running in parallel (this our case), one resets the resource used by the other.
Although the context of our project is a bit specific, still this sharing is not so clean. I'd rather prefer to have each resource referenced only by the testSuite where it is used. The tests should get access to the resource through some reference to their respective test suite.
Noury
On 1 mars 2013, at 10:57, Noury Bouraqadi wrote:
Thanx Camillo !
You are right. I tried in a **clean** 1.4 image and I got the behavior I expected initially. I don't know why in our robotic code we have a strange behavior. BTW, we had put a halt in the middle of the SUnit code (I don't remember where exactly), and got a hang, that we could interrupt, but then all we could see was decompiled code. So, we end up just reading the code and we got surprised with the code that does the reset in TestCase>>run.
Noury On 1 mars 2013, at 00:00, Camillo Bruni wrote:
Sorry if I may ask so bluntly, but did you read how TestResource work?
Because if I check in a 2.0 image they works as expected and are only initialized once per test.
you add the class to
MyTestCase >> #resources ^ Array with: MyResources
and initialize all the values you need in the resources
MyResources >> #setUp super setUp myValue := #foo
MyResources >> #myValue ^ myVale
then in the test case you access the resources via it's singleton pattern
MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo
and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite
On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
On Mar 1, 2013, at 12:20 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Interesting point. We'll think about that for SUnit 5.0.
I would really like to have a working/discussion group on Sunit 5.0 I'm not happy because I gave feedback to niall when esug was at brest and nothing happen since then. Stef
The easiest solution for you is to subclass TestResource & make TestResource>>current to look into some thread-local variable. You may need to fix isAvailable/makeAvailable (depends on version s SUnit you guys have)
Cheers, Jan
On 01/03/13 10:31, Noury Bouraqadi wrote:
I figured out the origin of the problem. Resources are used based on a default instance (TestResource class>>current). So, in case there are two test suites running in parallel (this our case), one resets the resource used by the other.
Although the context of our project is a bit specific, still this sharing is not so clean. I'd rather prefer to have each resource referenced only by the testSuite where it is used. The tests should get access to the resource through some reference to their respective test suite.
Noury
On 1 mars 2013, at 10:57, Noury Bouraqadi wrote:
Thanx Camillo !
You are right. I tried in a **clean** 1.4 image and I got the behavior I expected initially. I don't know why in our robotic code we have a strange behavior. BTW, we had put a halt in the middle of the SUnit code (I don't remember where exactly), and got a hang, that we could interrupt, but then all we could see was decompiled code. So, we end up just reading the code and we got surprised with the code that does the reset in TestCase>>run.
Noury On 1 mars 2013, at 00:00, Camillo Bruni wrote:
Sorry if I may ask so bluntly, but did you read how TestResource work?
Because if I check in a 2.0 image they works as expected and are only initialized once per test.
you add the class to
MyTestCase >> #resources ^ Array with: MyResources
and initialize all the values you need in the resources
MyResources >> #setUp super setUp myValue := #foo
MyResources >> #myValue ^ myVale
then in the test case you access the resources via it's singleton pattern
MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo
and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite
On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
On 01/03/13 12:19, stephane ducasse wrote:
On Mar 1, 2013, at 12:20 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Interesting point. We'll think about that for SUnit 5.0.
I would really like to have a working/discussion group on Sunit 5.0 I'm not happy because I gave feedback to niall when esug was at brest and nothing happen since then.
Not entirely true. In Barcelona, me and Niall merged some of stx fixes into SUnit 4.0 and Niall spent a __lot__ of time questioning people behind various dialects to find out what he could cleanup. Last summer, we had a coding session and started with 'to-be-5.0' by integrating St/X SUnit (based on 4.0) and SUnitToo. St/X changes mainly involves better support for interactive and reporting tools (such as one that generates JUnit-style reports), refactoring to ease customization and changes to allow integration with other testing frameworks (like JUnit and GNU Testlet, mainly used by STX:LIBJAVA). During last ESUG's CS Niall finished the merge in VW and I have to merge it back to St/X. My shame, this haven't happened yet - no time. I should do it. So, feel free to go to Cincom's Public Repository and have look at Niall's last development version and see now "nothing" look like :-) Jan
Stef
The easiest solution for you is to subclass TestResource & make TestResource>>current to look into some thread-local variable. You may need to fix isAvailable/makeAvailable (depends on version s SUnit you guys have)
Cheers, Jan
On 01/03/13 10:31, Noury Bouraqadi wrote:
I figured out the origin of the problem. Resources are used based on a default instance (TestResource class>>current). So, in case there are two test suites running in parallel (this our case), one resets the resource used by the other.
Although the context of our project is a bit specific, still this sharing is not so clean. I'd rather prefer to have each resource referenced only by the testSuite where it is used. The tests should get access to the resource through some reference to their respective test suite.
Noury
On 1 mars 2013, at 10:57, Noury Bouraqadi wrote:
Thanx Camillo !
You are right. I tried in a **clean** 1.4 image and I got the behavior I expected initially. I don't know why in our robotic code we have a strange behavior. BTW, we had put a halt in the middle of the SUnit code (I don't remember where exactly), and got a hang, that we could interrupt, but then all we could see was decompiled code. So, we end up just reading the code and we got surprised with the code that does the reset in TestCase>>run.
Noury On 1 mars 2013, at 00:00, Camillo Bruni wrote:
Sorry if I may ask so bluntly, but did you read how TestResource work?
Because if I check in a 2.0 image they works as expected and are only initialized once per test.
you add the class to
MyTestCase >> #resources ^ Array with: MyResources
and initialize all the values you need in the resources
MyResources >> #setUp super setUp myValue := #foo
MyResources >> #myValue ^ myVale
then in the test case you access the resources via it's singleton pattern
MyTestCase >> #testResourceMyValue self assert: MyResources current myValue equals: #foo
and I put a `self halt` in MyResources>>#setUp which only gets called once per TestSuite
On 2013-02-28, at 22:31, Noury Bouraqadi <bouraqadi@gmail.com> wrote:
Hi Mariano,
On 28 févr. 2013, at 20:16, Mariano Martinez Peck wrote:
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote: Hi,
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run. This happens when resources are declared in test class method resources.
My understanding of resources is that they should be reset only once for a whole test suite. For every test case, they should be setUp/tearDown, but not fully reset.
I don't know what the problem is, but yes, it should be as you said. If this is not the case, then there is a bug. wait a minute...what do you mean by "reset" of resources? I guess you mean #setUp, right?
No, no, it's reset. Meaning that the current instance of the resource is replaced by a new one. See :
TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result
We couldn't find a clean way of working this out. We ended up defining our own subclass of TestSuite, which I believe is dirty. Besides, the behavior is kind of random. It seems that there are some cleanups that aren't performed the right time. But, since the failure is random, we couldn't manage today to fix this.
Any hint, idea is welcome, Noury Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
-- Mariano http://marianopeck.wordpress.com
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Noury -- http://twitter.com/#!/NouryBouraqadi http://car.mines-douai.fr/noury
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
Afin de contribuer au respect de l'environnement, merci de n'imprimer ce courriel qu'en cas de necessite
Please consider the environment before you print
Not entirely true. In Barcelona, me and Niall merged some of stx fixes into SUnit 4.0 and Niall spent a __lot__ of time questioning people behind various dialects to find out what he could cleanup.
Last summer, we had a coding session and started with 'to-be-5.0' by integrating St/X SUnit (based on 4.0) and SUnitToo. St/X changes mainly involves better support for interactive and reporting tools (such as one that generates JUnit-style reports), refactoring to ease customization and changes to allow integration with other testing frameworks (like JUnit and GNU Testlet, mainly used by STX:LIBJAVA).
During last ESUG's CS Niall finished the merge in VW and I have to merge it back to St/X. My shame, this haven't happened yet - no time. I should do it.
So, feel free to go to Cincom's Public Repository and have look at Niall's last development version and see now "nothing" look like :-)
Good to know. This is still strange that nobody ever contacted us. I have no idea about integration/creation of points that I reported in 2009. I do not know if there is a list of features that I have been considered and/or integrated. For example knowing if the test were green when the application/tests were committed. Now when there will be a real release we will see if we port it. May be being able to load the two versions side by side would be good. Stef
Good to know. This is still strange that nobody ever contacted us. I have no idea about integration/creation of points that I reported in 2009. I do not know if there is a list of features that I have been considered and/or integrated. For example knowing if the test were green when the application/tests were committed.
That's possible because now test last test outcome (pass,error,fail) is remembered so tools can ask whether the test passed or not. The rest is dialect/SCM specific.
Now when there will be a real release we will see if we port it. May be being able to load the two versions side by side would be good.
That's for what namespaces are :-) You might need to sed-edit the fileout or hack monticello load and add some prefix when loading. Jan
Stef
On Mar 1, 2013, at 5:39 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Good to know. This is still strange that nobody ever contacted us. I have no idea about integration/creation of points that I reported in 2009. I do not know if there is a list of features that I have been considered and/or integrated. For example knowing if the test were green when the application/tests were committed.
That's possible because now test last test outcome (pass,error,fail) is remembered so tools can ask whether the test passed or not.
do you know how it is done?
The rest is dialect/SCM specific.
Now when there will be a real release we will see if we port it. May be being able to load the two versions side by side would be good.
That's for what namespaces are :-) You might need to sed-edit the fileout or hack monticello load and add some prefix when loading.
It could be by design. SUnit changes so much that we could even give another name to the classes that compose it.
Jan
Stef
On 01/03/13 16:57, stephane ducasse wrote:
On Mar 1, 2013, at 5:39 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
Good to know. This is still strange that nobody ever contacted us. I have no idea about integration/creation of points that I reported in 2009. I do not know if there is a list of features that I have been considered and/or integrated. For example knowing if the test were green when the application/tests were committed.
That's possible because now test last test outcome (pass,error,fail) is remembered so tools can ask whether the test passed or not.
do you know how it is done?
Indeed. I did it. There's a classInstVar, see TestCase class>>#rememberOutcome: https://swing.fit.cvut.cz/hg/stx.goodies.sunit/file/5cf0a462356a/TestCase.st I think Niall changed it to an external (WeakIdentity)Dictionary in his last version. I forgot the rationale, but I agreed. It was because of VW & SUnitToo, IIRC.
It could be by design. SUnit changes so much that we could even give another name to the classes that compose it.
DNU. Jan
sounds really interesting. I want this features since long time. So where can I find the latest maintained version of SUnit? Stef
On 02/03/13 09:03, stephane ducasse wrote:
sounds really interesting. I want this features since long time. So where can I find the latest maintained version of SUnit?
The current version for St/X maintained by me could be found at https://swing.fit.cvut.cz/hg/stx.goodies.sunit/ (branch default) or at http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/sunit/ For VW, it suppose it lives in Cincom's public repository. Jan
thanks I will have look.
On 02/03/13 09:03, stephane ducasse wrote:
sounds really interesting. I want this features since long time. So where can I find the latest maintained version of SUnit?
The current version for St/X maintained by me could be found at https://swing.fit.cvut.cz/hg/stx.goodies.sunit/ (branch default) or at http://www.exept.de/cgi-bin/viewvc.cgi/stx/goodies/sunit/
For VW, it suppose it lives in Cincom's public repository.
Jan
Noury Bouraqadi-2 wrote
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run
* Which Pharo version? * Are you running the tests from the TestRunner or Nautilus? There was a known bug in Nautilus that was integrated in 20552 (Issue 7510: Nautilus should run a class's tests as a suite http://code.google.com/p/pharo/issues/detail?id=7510) -- View this message in context: http://forum.world.st/Test-Resources-tp4672769p4672799.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hi Sean, We are working in 1.4, but the code is the same in 2.0 See the ensured block in TestCase>>run | result | result := self classForTestResult new. [ self run: result ] ensure: [ self classForTestResource resetResources: self resources ]. ^ result On 28 févr. 2013, at 21:29, Sean P. DeNigris wrote:
Noury Bouraqadi-2 wrote
Jannik and I are having trouble dealing with resources in our robotic project. It's strange that resources are reset on every test run
* Which Pharo version? * Are you running the tests from the TestRunner or Nautilus?
There was a known bug in Nautilus that was integrated in 20552 (Issue 7510: Nautilus should run a class's tests as a suite http://code.google.com/p/pharo/issues/detail?id=7510)
-- View this message in context: http://forum.world.st/Test-Resources-tp4672769p4672799.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --
participants (7)
-
Camillo Bruni -
Frank Shearar -
Jan Vrany -
Mariano Martinez Peck -
Noury Bouraqadi -
Sean P. DeNigris -
stephane ducasse