On Tue, Dec 22, 2009 at 1:37 AM, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
Stéphane Ducasse <stephane.ducasse@...> writes:
- get the same API (I think that sharing code amongst smalltalk is a too large constraint but having the same API is important)
Yes, legacy tests should keep running.
On the other hand, what is an API in Smalltalk? We just got methods, and they are *all* public. So when cleaning SUnit we have to draw a line. No doubt, #assert: and friends are API, but what about eg #runCase?
- integrate key features of extensions so that SUNIT and SUNITExtended is cooler.
Is "SUNITExtended" a project for Pharo?
- check what keith did on his Sunit extensions
Where can I find those? Which keith, email?
I think it is this: http://www.squeaksource.com/Testing http://wiki.squeak.org/squeak/SUnit%20for%203.10 And there is also some extensions made by Hernán Wilkinson. Maybe they are of help. They are here: http://www.squeaksource.com/SUnitExtensions Cheers Mariano
- have expected failures - have the possibility to know whether a test was red or green when it was saved and now when I run it, is it my fault or what is just before like that
+1 ... no, +100 :)
- add expectations matchers as used in behavior-driven testing Please not keep this separated or in another package.
Users should be free to choose between assertions and expectations. Assertions will stay.
- break testcase into two classes, and to run the test and one to store the result (no more #cleanUpInstanceVariables hack to avoid memory leaks)
what would be the impact on existing subclasses?
There should be none.
Tools however might have to be changed, since a test result will contain test descriptions rather than zombified test cases.
I suggest the following - clean and get a strong core - make sure that all the tests still run - get a set of extensions that people can load
To me, the effort of cleaning up Sunit is worthwhile if we get a strong core with support for test dependencies in the core. Phexample as an extension that people can load is what we have now. What I imagine is a simple core with clearly defined API, that allows other to write their own runners for their test classes. For example, I would like to separate the role of running tests and of containing tests (see my comment on class TestCase in the reply to Julien.) This should allow better extensibility for everyone.
--AA
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project