George Herolyants <george.herolya...@...> writes: > 2009/10/29 Dennis Schetinin <chae...@...>: > > Using symbols (i.e. "almost" constants) instead of explicitly telling what > > is happenning (sending a message) is more clean?! :) Ok then... (Not sure > > what you mean by "declarative" here) > > The message "given:" tells that to you. And by "declarative" I meant > the way you specify dependencies between your tests. If it was done > your way, test would be performed twice. If you use symbol, you don't > have to do it (haven't seen the library yet, just guessing :).
Genau. By the principle of least surprise (of which I am also a big supporter) one would expect to just being able to call the perquisites. However in our case we need (and want) declarative dependencies, such that the framework may interfere between "producing" and "consuming" test. If tests would directly call one an other, as suggested, we cannot interfere. Being able to interfere "calls" between tests allows the framework to control of how tests are executed. We use this to skip tests that depend on failed tests. Eg, if you introduce a failure in ForExampleStack >> #shouldPush, what you get are not 4 failures but 1 failure and 3 expected failures! Also, interfering "calls" between tests allows the framework to choose a strategy for multiple dependencies. If two or more tests depend on the same produce we can: a) run the producer n times or b) run the producer once, cache the result and clone it n times. Currently we simply rerun the tests, but for the future it should be possible to choose between these two strategies. My experience from JExample is that rerunning is often faster, since initializing objects is much faster then cloning them, I expect this tradeoff might differ in Smalltalk though :) cheers, AA _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
