links to this page:    
View this PageEdit this PageUploads to this PageHistory of this PageTop of the SwikiRecent ChangesSearch the SwikiHelp Guide
Last updated at 1:03 pm UTC on 16 January 2006
Some work is now on SM, see SUnit Test Runner in 3.8's latest version.

A blackboard to lay down ideas for the next version of
SUnit Test Runner in 3.8. We want to have easier access to
testing information . And easier manipulation of the test.
That way we may end with a fully-tested Squeak :-).

Main axes :
(TODO : neatly recategorize all the items down there in the categories)
All of this to encourage people to test things !

So here they are :

Test-specific refactorings : additional items in the RB while browsing a TestCase.
This seems an interesting path to explore.

Some ideas for BrowseUnit


594 of 617 sends of #assert: in a current image are sent in a unit test.
I think this is a bad thing, because


Enhance the notion of a method test in the following way:
A method is tested by some unit test, if
(Sorrow, OOPAL and Lispy Forth)

So, in short, you want to use pre and postconditions instead or in addition of standard unit tests ?

In addition. I mean that is what "both sides" get wrong: The design by contract -people overrate the abstract and the XPers the concrete part. Truth is like always somewhere inbetween ;-)
We need the concrete scenarios (method examples) as inputs for the abstract assertions. How should the-damned-to-be-concrete unit tests otherwise cope with the more and more abstract programs?

That's quite a drastic change of focus ... how does that fit with method examples ?

No - and very well I think. A method example is a test, if

There's some stuff about implementing assertions by modifying the compiler there :
http://www.smalltalkchronicles.net/edition2-1/st_compiler.htm. –
Romain Robbes
But we already have the assert: in Object>>assert:
So one could easily modify this to be executed on a per package basis, and add some global triggers. – Sorrow, OOPAL and Lispy Forth
That could be the first version. Vassily's approach (I reread quickly the article) says that it can impose no overhead at all, so it would be interesting in the long run. – Romain Robbes