On 01/03/13 12:19, stephane ducasse wrote:
On Mar 1, 2013, at 12:20 PM, Jan Vrany <[email protected]> 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 <[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
