On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <[email protected]>wrote:
> Hi Laurent, > > I like Autotest. It is true that I always execute the test after modifying > it. > There are three horizontal panes. Why so? Is it just to open a debugger > when necessary? > I want to be able to open a debugger from autotest. I agree the GUI is crap now. > We could imagine one standalone button instead with a green color to say > the test I just edited is green, and yellow or red when it fails. In that > case, clicking on the button open a debugger. > > I just feel the window of autotest takes a lot of space in the screen, > without having a real benefit. > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to make GUI now :) If you look at Autotest package, AutotestView is just the GUI, so we can implement several GUI and see the best solution. I need to take the time to do it, repository is read / write so feel free to commit :) What I want to have is a dashboard docked on one side of the screen which acts like you're driving a car. It's always visible, you have to be able to look quickly at it as when you check the speed of your car, adjust your drive, .... Also another problem with the current version if that if a test fails, change it and fails again, you don't see it has run (nothing moves in the GUI). Finally, another problem is that you see that a test has failed, but you don't know why (SUnit TestRunner has the same problem). I want to display the exception message too. Thanks a lot for feedback. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ > > Cheers, > Alexandre > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > Hi, > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no > tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > Load it: > > Gofer new > > squeaksource: 'Autotest'; > > package: 'Autotest'; > > load > > > > Open it: > > AutotestView open > > (there's en entry in WorldMenu > Tools) > > > > And change a tested method to see the results. > > > > There's a bug I need to find, maybe someone knows: > > - Change Bag>>occurrencesOf: > > - Autotest gives: > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 > unexpected passes > > Failures: > > CollectionRootTest>>#test0FixtureIterateTest > > > > Errors: > > CollectionRootTest>>#testBasicCollect > > CollectionRootTest>>#testDoWithout > > > > but in SUnit CollectionRootTest gives > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected > passes ?? > > > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <[email protected]> > wrote: > > The idea is excellent. > > > > Cheers, > > Alexandre > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <[email protected]> > wrote: > > > > You may have a lot of noise. > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. The > closest Smalltalk/Pharo has is the class and the package. > > > > > > > > I would suggest that TestCase which would use this feature use some > pragma/method to identify/declare which classes/packages this test depends > upon. Then the "autotest" framework would register such tests and listen for > changes in the given classes/packages, launching required tests whenever a > change happen. > > > > > > > > Additionally, one could declare such a pragma on a single test > method, when this test should be run for a specific class. > > > > > > > > Of course, you also to take care of long running tests, which you > probably want to exclude from auto-testing. > > > > > > I see autotest in Pharo in a slighly different way: When I press save > in the Monticello browser, I have a popup menu which asks me whether (i) I > want to run all the tests or (ii) only the tests that cover that I changed > from the last version. > > > > > > Does this make sense? > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly > look at test results if I want (or not) without stop writing. Often you want > to see your tests failing, as you type / save code. I don't have to stop > writing, click a button, wait test results, go again.... testing is done in > background and I just see notifications whether it's OK or not. > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > For autotest unit of work is file: it runs the test file which has the > same name as the code file, but you can customize this behavior. For > autotest-rails: > > > "A simplified version of Autotest heuristics in this mode would be: > > > When changing a test file, only this file is run (e.g. > test/unit/foo_test.rb →test/unit/foo_test.rb). > > > When changing a model file, only associated unit test file is run > (e.g.app/models/foo.rb → test/unit/foo_test.rb). > > > When changing a controller file, associated functional test file is run > (e.g.app/controllers/foo_controller.rb > →test/functional/foo_controller_test.rb). > > > When changing a fixture file, associated unit test and functional test > are run (e.g.app/fixtures/foos.yml → test/unit/foo_test.rb > +test/functional/foo_controller_test.rb). > > > When changing a helper file, associated functional test file is run > (e.g.app/helpers/foo_helper.rb →test/functional/foo_controller_test.rb). > > > When changing application_helper.rb file all functional test files are > run (e.g.application_helper.rb → test/functional/*_test.rb). > > > When changing a file under the config directory, all tests are run." > > > > > > Laurent > > > > > > > > > > > > Cheers, > > > Alexandre > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [email protected] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > [email protected] > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
