You might want to look at the SUnit browser in Dolphin. Its appearance is
great. The way it works is pretty much like every other test runner I have
seen: it's nice for verifying the all is well; it stinks for working with
failing tests. For the latter, I find there is no competition (yet anyway) for
a TesCase class side method called #prod: which runs a single test method and
either does nothing (good news) or raises a walkback. That goes straight to
the problem and there is no worrying about what the tool is going to "think of
next" in terms of losing context. At times I have gone so far as to create
methods that run tests referencing a class or selector, etc., but I tend to
lose track of them. #prod: is perennial.
Bill
________________________________________
From: pharo-project-boun...@lists.gforge.inria.fr
[pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Benjamin Van
Ryseghem [benjamin.vanryseg...@gmail.com]
Sent: Thursday, September 02, 2010 6:30 PM
To: pharo-project@lists.gforge.inria.fr
Subject: [Pharo-project] TestSprinter
Hello everybody
I'm now working on a new Test Runner tool and I wonder which behaviours do you
want me to implement.
For now, I want the Test Sprinter to be able to :
- search through packages and classes thanks to search fields.
- browse the hierarchy from packages to test methods (with icons).
- create groups of tests easily re-runnable.
If you have any ideas, I'm waiting for them ;)
Thank you
Ben
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
