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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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 >> >> >> >> >> > >
