March 2013 - Pharo-dev - lists.pharo.org

[Pharo-project] [update 2.0] #20577

by Marcus Denker

20577 ----- Issue 7624: #condenseSources should not do a CompiledMethod cleanUp http://code.google.com/p/pharo/issues/detail?id=7624 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Support-MarcusDenker.796.diff

March 1, 2013

Re: [Pharo-project] Test Resources

by stephane ducasse

> 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

March 1, 2013

Re: [Pharo-project] Test Resources

by Jan Vrany

On 01/03/13 12:19, stephane ducasse wrote: > > On Mar 1, 2013, at 12:20 PM, Jan Vrany <jan.vrany(a)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(a)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(a)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 >>> >>> >>> >>> >>> >> >> > > >

March 1, 2013

Re: [Pharo-project] Test Resources

by stephane ducasse

On Mar 1, 2013, at 12:20 PM, Jan Vrany <jan.vrany(a)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(a)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(a)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 >> >> >> >> >> > >

March 1, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by stephane ducasse

On Feb 28, 2013, at 3:00 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > tinchodias wrote >> Are you talking about an specific pragma for deprecation? I didn't catch >> it. > > I was thinking of something like <safeForMethodFinder>, but agree with > Marcus's objection that those would have to be sprinkled everywhere in the > system. It solves one problem, but creates anotherâ¦ why? because this is only for important core methods so

March 1, 2013

Re: [Pharo-project] Test Resources

by Camillo Bruni

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(a)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(a)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(a)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 >> >> >> >> >> > >

March 1, 2013

Re: [Pharo-project] String asPacked/fromPacked:

by stephane ducasse

>> > If possible it should abstract away from MethodFinder and encode something > about side-effectsâ¦ > > Or one could have some form of sandboxed secure environment to run > stuff and it's not a problem if there are side effects. > > It's all not easyâ¦ doing MethodFinder right is very hard. > Up to the point that the trivial thing there is now is the actually the sweet spot? > > Of course the code is horrible, absolutely horribleâ¦ I even removed it in the > development phase of 1.0 once, because it is just ugly and referencing so many > symbolsâ¦ but it is a fun demo. Method Finder is not a demo it is a really powerful tool. So we should invest in it Stef > Now how can one implement that fun demo > "For real"? > > Having the info that a method can be called safely actually could be interesting > for other things, e.g. random testing. http://code.google.com/p/yeti-test/ > > Marcus > >

March 1, 2013

Re: [Pharo-project] test job

by stephane ducasse

On Feb 28, 2013, at 3:23 PM, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > On Feb 28, 2013, at 1:48 PM, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > >> +1 >> >> I want everything automatic :) > > Even the integration process ? :) Somehow. But I want that one human really reads any code integrated. Stef > > Ben > >>>> I made a multidimensional matrix test job running each VM twice >>>> >>>> https://ci.inria.fr/pharo/job/Pharo-2.0-Tests/ >>>> >>>> maybe a slight overkill for now, but at least you should spot irregularities easier.. >>> >>> :-) >>> >>> I like how a automatic build and a build server at first seems useless >>> ("I can do that, too, I don't need that, I compile the VM after changing it anyway"). >>> >>> And then later it starts that one does things that one could never ever even think >>> about doing manually. >>> >>> Marcus >> >> > >

March 1, 2013

Re: [Pharo-project] Test Resources

by Jan Vrany

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(a)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(a)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 > > > > >

March 1, 2013

Re: [Pharo-project] Test Resources

by Noury Bouraqadi

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(a)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(a)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

March 1, 2013