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!<http://go.microsoft.com/?linkid=9734381>