Adrian Kuhn wrote: > > We got some more ideas (... search in test results) >
Is there a way to see which tests invoked a given method? Sometimes you're trying to understand a method, to see if it does what you're trying to achieve. In such cases, it would be really handy to see which tests used a given method during a system-wide test, and then invoke one of those to give you a handle on the method. Does such a thing already exist? ...Stan > Niko and me are thinking about doing some work on SUnit. > > Background is that we are working on Phexample, which extends SUnit with > test > that expand on one another [1]. We got test dependencies working with the > current SUnit, but had to do some quick ugly hacks. So we thought about > cleaning the internals SUnit up, and then include test dependencies in > the > core. > > Things we would possible change (we will certainly identify more as we > clean > up SUnit...) > > - store test resources in a dynamic variable rather than a static one > - refactor the assert: protocol to a trait, such that they can be used in > setup and teardown of test resources as well (actually I already did > that, > you can find a version on my squeaksource account) > - apply the fixes to test resources in Niall's slide deck that Lukas > showed us > - add expectations matchers as used in behavior-driven testing > - break testcase into two classes, and to run the test and one to store > the > result (no more #cleanUpInstanceVariables hack to avoid memory leaks) > - add test dependencies to test results, such that one test can extend on > the > return value of another test > - fix expected failures such that they are a first-class result (no more > #shouldPass with O(n^2) or worse behavior) > > So you see, the idea is twofold: first to clean up what is there, and > second > to add test dependencies as a new feature. For those that dont know test > dependencies. They had first been proposed by Markus Gälli based on an > analysis of all Squeak tests years ago. He found that most tests cover a > superset of another test's coverage set. A prototype in Java as been > implemented later by Lea Hänsenberger and me. We published a case study > at > XP 2008, which lead to PHP folks to include test dependencies in the > latest > PHPUnit. The idea of explicit test dependencies is to shift the burden of > isolating test cases from the developers to the framework. You avoid > duplicate test code and you get less red test cases per failure. Please > refer to Niko's blog post for more details [2]. > > We got some more ideas (such as API baseline testing, search in test > results, > etc...) but they will not likely make it into a first clean up. > > One thing we do not know is how many folks are out there that depend on > internal representation of SUnit. I talked to some folks and identified > two > requirements, first that legacy tests should keep running and second that > contributions to other sunit forks should keep being mergeable. The first > seems feasible, the second sounds like it boils down to not cleaning > anything :) > > What do you think? > > cheers, > AA > > [1]: http://www.squeaksource.com/phexample.html > [2]: > http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-expand-on.html > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- View this message in context: http://n4.nabble.com/SUnit-tp1297972p1752629.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
