Re: about long tests

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.

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project