> - 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?
you cut some line. > >> - integrate key features of extensions so that SUNIT and SUNITExtended is >> cooler. > > Is "SUNITExtended" a project for Pharo? yes for example. >> - check what keith did on his Sunit extensions > > Where can I find those? Which keith, email? keith hodges > >> - 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. For me expectations are already implemented in SSpec and keith merged them in his SUnit extensions and nobody used them and after he was not happy. So keep the core small concentrate on what is the key aspect we do not want a bloated SUnit. So tests dependencies seem important while expectations someextra features. We do not want NGUnit where you can also do the washing. > >>> - 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. ok > > --AA > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
