Tests and software process
johnson at cs.uiuc.edu
Wed Nov 1 20:50:13 UTC 2006
On 11/1/06, Keith Hodges <keith_hodges at yahoo.co.uk> wrote:>
> No development image should ever be shipped with any failing tests.
> -Ralph Johnson
> No development image should ever be shipped with any failing tests without
> some context to explain why they are failing.
> There may be tests that are intended to fail, particularly those that are
> intended to validate the external environment for a product. Of course the
> most annoying case being the example failure raising test case in SUnit that
> is placed there for beginners to see what a failure looks like.
> So, better to say, that no development image should ever be shipped with
> any failing tests that are associated with the domain of 'ensuring that the
> development image works as expected'. There may be other domains such as
> 'known bugs still to be fixed'.
The first thing I do when I start working with a new image is to
delete the SUnit tests. The one that always fails is especially
annoying. It is useful for people porting SUnit to a new platform,
but it is not useful to most people.
"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.
One of the main purpose of tests is to let you know when you broke
something. They will not have this function as long as some of them
fail. If tests fail then either 1) delete them 2) fix the code so
they no longer fail or 3) move them to a package on MC, or anywhere
not in the image.
More information about the Squeak-dev