Stéphane Ducasse <stephane.duca...@...> 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? > - 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
