On Mon, Jun 28, 2010 at 12:21 AM, Benoit St-Jean <bstjean@hotmail.ca> wrote:

Hi Laurent,

I have been playing with the Autotest tool and it's quite cool!

Thank you !

��

One major enhancement suggestion.

Let's say we have a test method defined as such:

testWhatever
�� ^self somethingElse or: [self testSomethingDifferent].

Removing the method #somethingElse or #testSomethingDifferent from the system won't trigger the listener to run the test #testWhatever since you only check for new methods and modified methods.

But what happens if we remove a method (called from a test method) and that would break the test?�� I think this should be handled as well.

Yes, you're right.

��

Besides, another suggestion, why wouldn't we queue the modified methods events instead of ignoring them when the current process is still running a test and has not yet completed?

First, when a second event occurs I may not have the time to see the result of the first event. Log can be a solution, but I have to click somewhere to open it or bloat the GUI.

Second, I've faced a problem when the tests call a method which programmatically add/modify/remove a method as it will send an event, run the tests again, event again and so on => infinite loop. So there may be a better solution but for now the simplest thing I've found is to process only the first event.

��

I also suggest that logging should include the test result (not only time & method name).

Yes it's planned + the list of all tests run so we can manually check heuristics.

��

Finally, thanks for such a great tool!

Thanks for feedback

Laurent

��

-----------------
Benoit St-Jean
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)

Turn down-time into play-time with Messenger games Play Now!