On Mar 16, 2010, at 6:28 PM, Ralph Boland wrote:

> I read a few Pharo posts lately about long tests.
> In this regard allow me to describe briefly some code I am now writing.
> I will eventually release this code to SqueakSource and, if the Pharo group
> is interested, I will port it to run on Pharo as well.

did you check the work of adrian kuhn on Sunit?
I'm interested in your work but I have to get into it.
What I would like is also a better way to which class I want to compute the 
coverage


> I use long tests a lot in development.  These tests are not really suitable as
> SUnit tests because they are too slow and some of them are parameterizable.
> These tests are meant for finding bugs during development; less so for 
> verifying
> code still works before a release.  However, I decided to use the SUnit idea 
> and
> code to enhance running these tests.
> 
> First, I refactored  TestCase by giving is a superclass and moving all
> the TestCase
> code into its superclass.  I then created a class RunnCase which has the same
> parent class as TestCase.  The reason for refactoring  TestCase this way
> is so that if  TestRunner is run the classes under RunnCase DO NOT SHOW UP.
> I now put my long tests into RunnCase subclasses.
> Note that I believe that TestCase should be so refactored even if you
> are not interested
> in using the tools I am building because it allows others to build
> their own tools just as
> I am doing.
> 
> I then subclassed  TestRunner with subclass TestPlusRunner.
> TestPlusRunner allows
> running the same tests as TestRunner.  TestPlusRunner is like
> TestRunner with a few
> minor changes including:
>    1) an extra window that displays individual test case methods when
> only one class
>        is selected. Subsets of test cases from an single class can be
> selected and run.
>    2) (Ignore this paragraph is you like)  it has as some additional buttons.
>        Currently the buttons are there but not the functionality.
>        The intent of the buttons is to be able distribute
>        the running of a set of tests over a number of computers and
> return to one
>        computer only the tests that failed so they can be debugged.
>        Specifically, the intent is to be able to file out a set of tests,
>        send them to another user/computer,  have that user/computer
> run those tests
>        and send back a file containing all the tests that fail,
>        and then be able to load the failed test and debug them.
> 
> I then subclassed  TestPlusRunner with subclass RunnRunner.
> RunnRunner runs tests
> of  subclasses of  RunnTest.  RunnRunner is like TestPlusRunner with
> the ability to set parameters that can affect the running of tests.
> Currently the only
> parameter that can be set are a list of size values.  For example, if
> this parameter is
> set to  '3-5,7,9-12'  then the tests that are run will be given this
> parameter and then
> use this parameter however they want but presumably either ignore it or run 
> the
> test once with each of the size values:  3,4,5,7,9,10,11,12.
> Several other parameters are also planned:
>    1) seed.  The seed is a value with which to initialize a random
> number generator
>        that the tests can optionally use in the generation of test
> data for the tests.
>    2) number of subtests.   A test may have the ability to generate
> and run a number
>        of subtests (probably using 1)).  This parameters indicates
> how many subtests to
>        run.
>    3) subtest start.   If a test runs 1000 subtests and then detects
> a failure then the user
>        may not want to rerun the first 999 subtests before running
> subtest 1000 again.
>        This parameter allow the subtests to be run starting at subtest #1000.
> 
> Feedback on this work is most welcome either positive or negative (but
> constructive).
> Regardless of opinions, it would be great if the refactoring of
> TestCase described
> above were done.  It is the way it should have been written in the first 
> place.
> Note that some additional minor refactoring of TestCase and TestRunner
> is required.
> Email me if you want details.
> 
> Regards,
> 
> Ralph Boland
> 
> _______________________________________________
> 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

Reply via email to