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

Re: [Pharo-project] Test Resources

by Camillo Bruni

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 > -- > > > >

Feb. 28, 2013

Re: [Pharo-project] Test Resources

by Noury Bouraqadi

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 --

Feb. 28, 2013

Re: [Pharo-project] Test Resources

by Noury Bouraqadi

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 --

Feb. 28, 2013

Re: [Pharo-project] Test Resources

by Sean P. DeNigris

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.

Feb. 28, 2013

Re: [Pharo-project] [update 2.0] #20575

by Sean P. DeNigris

EstebanLM wrote > Issue 7609: [Horrible Error]: Class creation not logged in changes > https://code.google.com/p/pharo/issues/detail?id=7609 Hooray! This one was extra frustrating :) -- View this message in context: http://forum.world.st/update-2-0-20575-tp4672750p4672796.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 28, 2013

Re: [Pharo-project] Kind of Stuff I would like to change in 3.0

by Frank Shearar

Right, gotcha. So you'd like to see a #protectedInstvars method that returned a collection of instvars not to be touched. Of course, you really want first class slots here, not just returning names of instvars. frank On 28 February 2013 19:05, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > Never put a constant in a method. How can I provide a different set of IVs? No way of doing it except rewriting the whole method, which is dirty. > > On 28 fÃ©vr. 2013, at 18:52, Frank Shearar wrote: > >> On 28 February 2013 15:46, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >>> TestCase>>cleanUpInstanceVariables >>> self class allInstVarNames do: [ :name | >>> name = 'testSelector' ifFalse: [ >>> self instVarNamed: name put: nil ] ] >> >> What is it that you find wrong about this? Its absence would cause a >> problem with Fuel, where the TestCases end up hanging onto obsolete >> classes. >> >> frank >> > > Noury Bouraqadi > Ecole des Mines de Douai > http://car.mines-douai.fr/noury > -- > > > >

Feb. 28, 2013

Re: [Pharo-project] Test Resources

by Mariano Martinez Peck

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? > 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

Feb. 28, 2013

Re: [Pharo-project] Test Resources

by Noury Bouraqadi

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(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. >> >> 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

Feb. 28, 2013

Re: [Pharo-project] Kind of Stuff I would like to change in 3.0

by Noury Bouraqadi

Never put a constant in a method. How can I provide a different set of IVs? No way of doing it except rewriting the whole method, which is dirty. On 28 fÃ©vr. 2013, at 18:52, Frank Shearar wrote: > On 28 February 2013 15:46, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: >> TestCase>>cleanUpInstanceVariables >> self class allInstVarNames do: [ :name | >> name = 'testSelector' ifFalse: [ >> self instVarNamed: name put: nil ] ] > > What is it that you find wrong about this? Its absence would cause a > problem with Fuel, where the TestCases end up hanging onto obsolete > classes. > > frank > Noury Bouraqadi Ecole des Mines de Douai http://car.mines-douai.fr/noury --

Feb. 28, 2013

Re: [Pharo-project] IslandVMTweaksTestCase and Memory corruption

by Fernando Olivero

Island are part of the TeaTime implementation in Croquet. If the tests are referring to that "Island" then why should Pharo include such tests? Fernando On Thu, Feb 28, 2013 at 4:23 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On Feb 28, 2013, at 4:15 PM, Ciprian Teodorov <ciprian.teodorov(a)gmail.com<mailto:ciprian.teodorov@gmail.com>> wrote: > > > No, I think that those tests should be shipped... And fix the VM to not corrupt the memory. That's only in the case these test are wrote in pure smalltalk. If they use ffi then yeah they should be removed > > They have primitives in methods for which the primitive was not written. > > On Feb 28, 2013 3:11 PM, "Marcus Denker" <marcus.denker(a)inria.fr<mailto:marcus.denker@inria.fr>> wrote: > > On Feb 28, 2013, at 3:09 PM, ClÃ©ment Bera <bera.clement(a)gmail.com<mailto:bera.clement@gmail.com>> wrote: > > Hello, > > I was looking for VM tests in the Pharo image and I found the class IslandVMTweaksTestCase. The strange thing is its comments : > "Test case for some tweaks to the VM that Islands requires. These tests are largely for documentation; with an un-tweaked VM, the tests mostly still succeed, albeit with possible memory corruption." > > Does that really mean if I run those tests it might result into memory corruption ? > > I don't think it is a good idea to ship Pharo with this memory corruption tests in IslandVMTweaksTestCase. I suggest that if the tests may really corrupt memory we remove them from Pharo, or if they cannot corrupt memory then we fix the memory corruption comment. > > Yes, we should not ship code like that. > > Marcus > >

Feb. 28, 2013