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 12:41 am UTC on 17 January 2006
by Markus Gaelli


If you start to program "test-first," you really start to program "example-first".

When you have examples for your system, you easily can run it and increase the coverage of the code executed. This coverage helps you to deploy minimal systems and make them more performant, as just in time compilers can be trained on them.

But examples are also essential for documenting and understanding a system.

Eg will be a collaborative space, which supports programmers to create and retrieve examples for objects and their behavior.

Agile programming and E-Toys

Agile programming and E-Toys are similar.

It is common knowledge, that the hard part of testing is the creation of the test-scenario. If you look into Unit-Tests, the code to setup the test is usually much longer than the call of the method or the following assertions. And the setUp comes first.

The same holds for E-Toys programming: first comes the concrete object, only then (and not always!) comes the abstraction.
So what do you do, when you want to program a new behavior and you are the kind of programmer, who likes to "do it" in the "debugger", because it is such a lively place?

This is exactly what you do, when you program with E-Toys:


I find it strange, that in test-first-programming with current object-oriented systems, you are supposed to write simple tests, which only hold for certain objects, but you start to satisfy them by writing methods, which work for any object as a receiver and any objects as parameters.

This is a bad smell, as I think that is very valuable to keep the complexity of the test and the program at the same level, look at the result of Daniel Hillis, when he co-evolved sorting-algorithms on the connection-machine:


He came much earlier to good results, when the complexity of the program (=sorting-algorithm) became bigger with the complexity of the test. (=Degree of order of the list, which was to be sorted). By introducing example-methods, the complexity of the first versions of the program better fits to the complexity of the first version of the test.

To co-evolve the test and the program means then, to insert abstract assertions into the program while you come up with more abstract solutions around your abstract assertions.

The examples are kept to be able to still execute the program and hence the assertions.

Building-Blocks and Tools

The building blocks of an object-oriented system are objects and methods, so these are also the entities we will exemplify:



Example-objects act as examples for objects.

They wrap our normal objects in a certain state and give them a name.
They are composed of other example-objects and immutable value-objects and can be stored and retrieved.

They can be stored, by creating factory-methods on the class-side, this factory-methods could call each other, to build up more complex example-objects.

I am not decided, if I want to use literal arrays or XML, to descibe the example-objects in the factory methods.

Any tips here?

The GUI for example-objects allows us to compose them out of existing ones or wrap value-objects, it also allows us to store and retrieve them. I imagine some nice tree-widgets and drag'n'drop-mechanism, I'll try StarBrowser, made by Roel Wuyts, who happens to sit one room next to me :-)

This leads to easy reuse and composition of "fixtures"=examples, as they are not bound to any tests like in XUnit.


0 >> factorial
	Integer >> factorial
	        self assert: (self > 0).
	        ^self * (self -1)

Example-methods are composed of example-objects, which serve as the receiver and the arguments of a method, and the method itself and they are executable, as there is a "running" instance for every object involved.

We can put the assertions (in principle - problems see below) directly into the example-methods, as they are valid exactly for this receiver and that parameters. See also the existing work of Ted Kaehler in Squeak: Classes MethodCall and Verifier

When I change my instance-specific code to be more general and refactor it into a "normal" instance-method,I keep the example-method, which provides me with examples and assertions.

The "normal" instance-method is then called from the example-method via "self class", because that is what I do here: I abstract the behavior from _this one_ object to _all_ objects of this class.

In detail the method-lookup would look like this:

So in principle a change of the lookup in the VM would be neccessary, as it has been discussed on the Squeak-dev-list recently:

I think, that I stick with some MethodWrapper-Tricks at the beginning to achieve that changed lookup. The plan is to wrap the methods, which have example-methods or are example-methods only, and then, by intercepting their evaluation, delegate the execution to the most concrete implementation of this method, which is stored in that wrapper. Not knowing a better place, I would suggest to store factories for example-methods also on their respective receiver-classes. Better alternatives somebody?

By having assertions in example-methods with the same name as the refactored instance-methods, I don't have to rename test-methods after I renamed the program-methods. General some refactoring of tests and methods under test should be easier or even possible in Habitat.

Maybe more important, example-methods bridge the mental gap between more abstract but not executable assertions like pre-/postconditions found in Eiffel, and concrete and executable assertions like XUnit:
I don't have to leave my browser to create tests anymore, neither if they are concrete or abstract.

Store / SqueakMap

It would be good, if we could store both example-objects and methods (or its factories) on an external Server like Store or SqueakMap, so that we could collaborate on creating examples. It might also give us some synergies, by sharing example-objects /-methods for the baseclasses of VisualWorks and Squeak.

It has to be seen, how this could be coordinated with some Maps/Packages, which are dedicated to testing.


Examples should have their own tab.
Uploaded Image: ExampleBrowser.gif


Swiss National Science Foundation :-)

Markus Gaelli