[V3dot10] Re: 3.10

[Philippe Marschall]

2006/12/14, Ralph Johnson <johnson at cs.uiuc.edu>:
> The testrunner is not standard, and so changes to it do not break SUnit.
>
> The reason SUnit doesn't change is because it is good enough.  Why
> break things that work?  It is used very heavily in VisualWorks.  We
> have lots of tests, some good and some not so good.  If we end up
> having to rewrite tests to work with a new testing framework, we will
> be spending a lot of time for nothing.

SUnit is not good enough for me. Just two simple examples:
-You can't categorize test
-- long running ones
-- platform specific ones
-- tests that need an internet connection
-- database tests
-- database tests that mess up the database :(
-- expected failures (yes that should be a category too)
-- I wan't to be able to combine these tests for lets platform
specific, long running ones
- You can't add a listener to a test rest results
I didn't even touch the subject of tests that depend on each other
e.g. reuse the result of a previous one. PhDs have been written about
this.

Honestly to me SUnit is seriously laking behind JUnit4. Isn't the sole
existence of SUnitToo proof of this?

I have seen an SUnit on VW demo this year at ESUG in the coding dojo.
How can people use this? First you have to scroll about two dozens of
stack frames until you are in the test and then you have to restart
the image or do whatever other magic to reset the method cache because
else the SUnit will just use the old method.

Let's face it, Smalltalk code is inherently not portable. It even
starts with simple things like #initialize. So why should we restrict
yourselves because some other platform doesn't provide a useful
feature that eases our life? Should every other Smalltalk not use full
closures because Squeak doesn't have them? Sure it would be nice if
SUnit would make our code portable but it doesn't even if we don't fix
it for years. In times of multi byte strings, namespaces, traits and
pragmas unportability is only increasing. Let's not pretend otherwise.

Philippe