On Tue, Apr 6, 2010 at 7:03 AM, Stan Shepherd
<stan.shepherd414@gmail.com> wrote:
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
> Pharo-project@lists.gforge.inria.fr
> 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
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project