Tests and software process
keith_hodges at yahoo.co.uk
Wed Nov 1 21:52:52 UTC 2006
> "Known bugs still to be fixed" should be a separate package that you
> can load if you are going to fix the bugs. There should not be any
> SUnit tests like that in a released, stable image. Not even in an
> alpha or a beta image.
This might be an ideal, but I don't think that it is practical, since an
individual bug to fix test may well (should) exist in the context of the
other tests for that package/set of functionality. Making a separate
change-set or package for such a test just seems too much. Once the fix
is made then the individual bug-test method from the
separate-bugs-to-fix-package would then have to be integrated etc etc.
I would prefer to have the full information available to me in order to
assess the state of an image, whether declared stable or not. For me the
50 or so tests that fail in the 3.9 image would be ok if they were in a
"tests we expect to fail" category.
With the scheme I propose, you select the "tests for release 3.10"
category of tests, and hit run, if all the tests pass then great. The
existence of miscellaneous snippets of code in the image that are not
part of that category is simply an ignorable artefact for the purpose of
validating that release. Those snippets might be named #bugtestMyBug or
#release39Test or #extraLongTest.
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
More information about the Squeak-dev