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

Reply via email to