Tests and software process

Lex,

Although right now I feel I might need to go back and read Howards posts
in order to try and learn from history. This is similar to the scheme
that I described in my previous post as an extension to SUnit.

to illustrate with your example

TestCase-c-publishedSuites
^ #( #allStandardTests #pendingTests)

TestCase-c-allStandardTests
^ 'test*'

TestCase-c-pendingTests
^ 'pendtest*'

Keith

p.s. if you try the code on www.squeaksource.com/Testing please read the
project notes on squeaksource, and the wiki, it is not a straight
forward load into 3.9, it is still very much in development.

               
___________________________________________________________
Copy addresses and emails from any email account to Yahoo! Mail - quick, easy and free. http://uk.docs.yahoo.com/trueswitch2.html

Keith Hodges <[hidden email]> writes:
> Although right now I feel I might need to go back and read Howards
> posts in order to try and learn from history. This is similar to the
> scheme that I described in my previous post as an extension to SUnit.

Nice!  Notice, thuogh, that you can use the pendtest prefix proposal
even using stock SUnit.  Programmers can rename the methods to turn
tests on and off.


-Lex

I actually like that you do not refer to groups of packages from
within code, nor that there are not a lot of operations on groups of
packages.  There is dependency satisfaction, and that's about it.
There is an image-wide set of packages, and an image-wide set of
tests.  Loading new packages and new tests simply adds to these sets.


The self tests included in packages fit in as a great sanity check
that a package is working in its current installation.  Note that
packages are developed independently, and that new versions are posted
all the time.  Additionally, different people load different
combinations of packages.  Self tests are important because a package
might test out fine on the developer's desktop, but still fail to work
when it is loaded on someone else's machine.


For these self tests to work, though, you need to know which test
failures really matter.  Ralph reports that this is not the case with
Squeak's unit tests right now: there are tons of test failures that
are simply known to be failures, so many that you cannot easily tell
when you have broken something new.

I believe that this last problem has had many great solutions
proposed, that we are not using any of them right now, and that we
should adopt one of them.  There is no big fundamental problem!  We
just need to mark which tests are expected to work, and which are not.


-Lex