[ANN] Eg, Examples to the rescue (prototype only...)

Markus Gaelli gaelli at emergent.de
Sat Apr 12 16:35:49 UTC 2003


Hi,

I've just put a bleeding edge version of "Eg" on SqueakMap.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: StarBrowser.gif
Type: image/gif
Size: 14519 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20030412/7e28ccf1/StarBrowser.gif
-------------- next part --------------


Eg helps programmers to create and retrieve examples for objects and 
their behavior including tests.

The current highlights include:

- You can store any object as a named example automatically (via SiXX 
as a factory-method on the class-side of the object,
but you also can just store any "storeString" (Thanks, Diego:-) in the 
example-method.

- You can create a test by dragging a method on an example and edit a 
concrete post-condition
(this will also be stored as a method on the class-side)
- you immediately debug a method, if all its receivers and parameters 
are known
- You can see the return-type (and the type of the method-parameters) 
via the balloon-help of a method

It is only a functional prototype, so don't expect it to replace SUnit 
very soon.

Long term goal, is to come up with something Andreas described today:
> (...) But the argument can be made that this is really a bug of the
> testing environment (I presume you're using SUnit like everyone else) 
> as it
> forces you to break encapsulation here. In fact, I'd claim that writing
> tests "outside" of the context of the class you are working on is one 
> of the
> primary reasons why people often _don't_ write tests. To me, the tests
> really should be embedded right into the method you're writing - making
> extra classes, accessors and the like just gets into your way and 
> detaches
> the place where you find the code from the place where you find the 
> test. It
> can be tremendously hard to guess in which class exactly you may find 
> a test
> (if any) for a certain method.

But that would include some  VM-changes, no?

What is also missing:
- Easily compose a test for a method with several parameters (drag and 
drop
in the parameters)
- Compose complex examples via dragging them into variables
- Composing tests, reuse of concrete assertions/post-conditions in more 
complex scenarios
- Documentation
- Organization of the tests
- Tests(!), done with the tool itself,
  (I thought, I'll make my hipocrisy public in the best possible way :-)
though I did a few tests, and hey, it is only a prototype, you are all 
invited to use it...
- Discussion, if this could lead to something useful:

What do you think?

Cheers,

Markus

Markus G?lli				   Software Composition Group
markus.gaelli at iam.unibe.ch	University of Bern, Switzerland
Office: +41(0)-31-631-3313		Fax: +41(0)-31-631-3355


More information about the Squeak-dev mailing list