Re: [Pharo-project] Test Resources
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
Re: [Pharo-project] Test Resources
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
Re: [Pharo-project] Test Resources
sounds really interesting. I want this features since long time. So where can I find the latest maintained version of SUnit? Stef
Re: [Pharo-project] Test Resources
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 TestCaserun. 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 bouraq...@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 bouraq...@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 : TestCaserun | 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
Re: [Pharo-project] Test Resources
I figured out the origin of the problem. Resources are used based on a default instance (TestResource classcurrent). 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 TestCaserun. 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 bouraq...@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 bouraq...@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 : TestCaserun | 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
Re: [Pharo-project] Test Resources
Interesting point. We'll think about that for SUnit 5.0. The easiest solution for you is to subclass TestResource make TestResourcecurrent 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 classcurrent). 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 TestCaserun. 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 bouraq...@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 bouraq...@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 : TestCaserun | 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
Re: [Pharo-project] Test Resources
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.vr...@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 TestResourcecurrent 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 classcurrent). 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 TestCaserun. 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 bouraq...@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 bouraq...@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 : TestCaserun | 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
Re: [Pharo-project] Test Resources
On Mar 1, 2013, at 12:20 PM, Jan Vrany jan.vr...@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 TestResourcecurrent 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 classcurrent). 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 TestCaserun. 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 bouraq...@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 bouraq...@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 : TestCaserun | 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
Re: [Pharo-project] Test Resources
On 01/03/13 12:19, stephane ducasse wrote: On Mar 1, 2013, at 12:20 PM, Jan Vrany jan.vr...@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 TestResourcecurrent 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 classcurrent). 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 TestCaserun. 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 bouraq...@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 bouraq...@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 : TestCaserun | 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
Re: [Pharo-project] Test Resources
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
Re: [Pharo-project] Test Resources
do you have a list =of features that have been added? that are planned? Dear Stephane, as Jan says, we had a good pair-programming session on SUnit in Glasgow. (I hope we'll have another when time permits.) I also have some stuff not yet in the OR (follow-on from my 10-min talk in Ghent) that improves/exploits TestResources. I am working to get this stuff visible so the community can comment (and porting help would be great too). It's been very busy here - and a month-long illness I had after Christmas has not helped. Points that I reported in 2009 Were these at an ESUG (in which case I should have notes) or somewhere else. I note what you say about test-state-when-committing (would need repository-specific implementations; one for Store, one for Monticello, ... ?) If any list of SUnit wishes is on the web somewhere that I should be (re)reading, by all means email (to the above email address for this topic) to remind me. My aim for soon (ideally for end-March, but I've lots to do - the illness put me behind) is to make the current work visible, after which more can be looked at. Looking forward to Annecy Niall Ross 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
Re: [Pharo-project] Test Resources
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
Re: [Pharo-project] Test Resources
On Mar 1, 2013, at 5:39 PM, Jan Vrany jan.vr...@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
Re: [Pharo-project] Test Resources
On 01/03/13 16:57, stephane ducasse wrote: On Mar 1, 2013, at 5:39 PM, Jan Vrany jan.vr...@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
[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
Re: [Pharo-project] Test Resources
On 28 February 2013 17:37, Noury Bouraqadi bouraq...@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
Re: [Pharo-project] Test Resources
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 bouraq...@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
Re: [Pharo-project] Test Resources
On Thu, Feb 28, 2013 at 2:37 PM, Noury Bouraqadi bouraq...@gmail.comwrote: 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
Re: [Pharo-project] Test Resources
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.
Re: [Pharo-project] Test Resources
Hi Sean, We are working in 1.4, but the code is the same in 2.0 See the ensured block in TestCaserun | 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 --
Re: [Pharo-project] Test Resources
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 bouraq...@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 : TestCaserun | 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 --
Re: [Pharo-project] Test Resources
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 bouraq...@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 bouraq...@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 : TestCaserun | 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 --
