Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]
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 <alexandre@bergel.eu>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 <alexandre@bergel.eu>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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? 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. 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu>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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 :)
Today I will not have time, but I will try to implement the "button listener" this week end to see.
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, ....
I like the idea of dashboard. There is something similar in Eclipse. It is really effective I feel.
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.
Yes, that would be interesting. One step forward in that direction is to exploit assert:equal:. We could imagine assert:include: and friends. Oscar proposed something like this some time ago. 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Laurent, I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this? Cheers, Alexandre On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
I've seen this, I like the idea of the background thread. We also should be able to tag long tests or exclude tests from Autotest. I'm currently experimenting with GUI (on my free time so I can't go very fast :). I think you are the only user :D Cheers. Laurent
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've seen this, I like the idea of the background thread. We also should be able to tag long tests or exclude tests from Autotest. I'm currently experimenting with GUI (on my free time so I can't go very fast :).
Maybe putting a timeout will be cool. Something like 500 ms per test method. Are you working on this? I will be glad to try it out and write tests for this. Cheers, Alexandre
Cheers.
Laurent
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mon, Jun 14, 2010 at 9:32 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I've seen this, I like the idea of the background thread. We also should be able to tag long tests or exclude tests from Autotest. I'm currently experimenting with GUI (on my free time so I can't go very fast :).
Maybe putting a timeout will be cool. Something like 500 ms per test method.
Are you working on this? I will be glad to try it out and write tests for this.
Repository is public write, don't hesitate to commit ! I will be happy to share experience with you on this. I've just commited a new version with more experimentations: - A new GUI. Open it with: AutotestDashboard open. To close: AutotestDashboard close. It's less intrusive and widget oriented (see AutotestAbstractWidget), so we can add more stuff without a big bloat class for GUI. - Only tests of the same package are run. Maybe a not so good idea, as I've seen tests and code are often not in the same package. What do you think ? Cheers, Laurent
Cheers, Alexandre
Cheers.
Laurent
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu>
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 < alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Alexandre, I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback. Cheers, Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute. Alexandre On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2). Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests. How would you name the tag ? Where the implementation should go ? (TestCase ?) Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 < alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution. Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice. We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-= Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-= I guess the tweak in SUnit to identify long tests should not be that hard to implement. Cheers, Alexandre On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-=
Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-=
I guess the tweak in SUnit to identify long tests should not be that hard to implement.
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive). I also think that execution time is not the only criteria. For example, Autotest can have a "feedback deadline" of 2 seconds. That means it can run: - 2 tests of 1 second - 20 tests of 100 ms So knowing execution times, Autotest can run as many tests as it can, starting from fastest to lowest. It seems that JUnitMax do this way. Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu>
wrote:
I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel < alexandre@bergel.eu> 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 < alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
I also think that execution time is not the only criteria. For example, Autotest can have a "feedback deadline" of 2 seconds. That means it can run: - 2 tests of 1 second - 20 tests of 100 ms So knowing execution times, Autotest can run as many tests as it can, starting from fastest to lowest. It seems that JUnitMax do this way.
Method consumption as well. A test that is fast to execute but require a lot of memory becomes slow. Alexandre
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen? Cheers, Doru On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
I also think that execution time is not the only criteria. For example, Autotest can have a "feedback deadline" of 2 seconds. That means it can run: - 2 tests of 1 second - 20 tests of 100 ms So knowing execution times, Autotest can run as many tests as it can, starting from fastest to lowest. It seems that JUnitMax do this way.
Method consumption as well. A test that is fast to execute but require a lot of memory becomes slow.
Alexandre
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu
wrote: I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2 ).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu
wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu
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 <alexandre@bergel.eu
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 <alexandre@bergel.eu
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet. Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
Ah, indeed! I forgot ... sorry for the noise :) Cheers, Doru On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "One cannot do more than one can do."
Hi, Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf and replace: counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount. by aTestResult := runner run: testMethods to check that the problem is here. I haven't tried Cog yet. Is it working out of the box ? Laurent On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba@gmail.com> wrote:
Ah, indeed! I forgot ... sorry for the noise :)
Cheers, Doru
On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test:
- min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test
methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Laurent, I have similar needs. I would like to extend SUnit before and after each test method. I was wondering about this: - Introduce a registration mechanism in SUnit (a bit like OB commands) - TestResult>>runCase: aTestCase can be enhanced by executing what has been registered before and after - A class TestCommand contains a method #before and #after. TestCommand define inst var #currentTestCase #currentTestMethod Advantages: - minor addition to SUnit We could then refactor the SUnit history to use a command. It would then be easy to have a logger or something. Does it make sense? cheers, Alexandre On 29 Jul 2010, at 11:08, laurent laffont wrote:
Hi,
Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf
and replace:
counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount.
by
aTestResult := runner run: testMethods
to check that the problem is here.
I haven't tried Cog yet. Is it working out of the box ?
Laurent
On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba@gmail.com> wrote: Ah, indeed! I forgot ... sorry for the noise :)
Cheers, Doru
On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Thu, Jul 29, 2010 at 11:24 AM, Alexandre Bergel <alexandre@bergel.eu>wrote
Laurent,
I have similar needs. I would like to extend SUnit before and after each test method. I was wondering about this:
- Introduce a registration mechanism in SUnit (a bit like OB commands) - TestResult>>runCase: aTestCase can be enhanced by executing what has been registered before and after - A class TestCommand contains a method #before and #after. TestCommand define inst var #currentTestCase #currentTestMethod
Advantages: - minor addition to SUnit
We could then refactor the SUnit history to use a command. It would then be easy to have a logger or something.
Does it make sense?
Yes, it doesn't seem hard to implement. Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ? Laurent
cheers, Alexandre
On 29 Jul 2010, at 11:08, laurent laffont wrote:
Hi,
Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf
and replace:
counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount.
by
aTestResult := runner run: testMethods
to check that the problem is here.
I haven't tried Cog yet. Is it working out of the box ?
Laurent
On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba@gmail.com> wrote: Ah, indeed! I forgot ... sorry for the noise :)
Cheers, Doru
On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ?
:-) synchronous. http://code.google.com/p/pharo/issues/detail?id=2721 SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.1 in PharoInbox I quickly wrote this. I haven't used it yet. Cheers, Alexandre
On 29 Jul 2010, at 11:08, laurent laffont wrote:
Hi,
Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf
and replace:
counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount.
by
aTestResult := runner run: testMethods
to check that the problem is here.
I haven't tried Cog yet. Is it working out of the box ?
Laurent
On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba@gmail.com> wrote: Ah, indeed! I forgot ... sorry for the noise :)
Cheers, Doru
On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Thu, Jul 29, 2010 at 4:58 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Is Annoucements framework is synchronous or asynchronous ? If synchronous, using Annoucements isn't less intrusive and more extensible ?
:-) synchronous. http://code.google.com/p/pharo/issues/detail?id=2721 SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.1 in PharoInbox
I quickly wrote this. I haven't used it yet.
Wow ! Fast !. That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. Laurent
Cheers, Alexandre
On 29 Jul 2010, at 11:08, laurent laffont wrote:
Hi,
Autotest use a wrapper to count hits on changed method. Take a look at
Autotest>>#findRunAndShowTestsOf
and replace:
counter := AutotestHitCounter on: changedMethod. <- this wraps
the method
[aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount.
by
aTestResult := runner run: testMethods
to check that the problem is here.
I haven't tried Cog yet. Is it working out of the box ?
Laurent
On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba@gmail.com>
wrote:
Ah, indeed! I forgot ... sorry for the noise :)
Cheers, Doru
On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool.
I will be in winter time in 1 week time. We have to enjoy now Alexandre
On 29 Jul 2010, at 11:08, laurent laffont wrote:
Hi,
Autotest use a wrapper to count hits on changed method. Take a look at Autotest>>#findRunAndShowTestsOf
and replace:
counter := AutotestHitCounter on: changedMethod. <- this wraps the method [aTestResult := runner run: testMethods] ensure: [counter uninstall]. aTestResult hitCount: counter hitCount.
by
aTestResult := runner run: testMethods
to check that the problem is here.
I haven't tried Cog yet. Is it working out of the box ?
Laurent
On Thu, Jul 29, 2010 at 10:48 AM, Tudor Girba <tudor.girba@gmail.com> wrote: Ah, indeed! I forgot ... sorry for the noise :)
Cheers, Doru
On 29 Jul 2010, at 10:45, Henrik Johansen wrote:
On Jul 29, 2010, at 10:40 55AM, Tudor Girba wrote:
Hi,
It looks like Autotest is crashing on a Cog VM/image. Any ideas as to why that happen?
Cheers, Doru
If he went for using MethodWrappers as described below, it will crash on Cog, as it does not support objects as methods yet.
Cheers, Henry
On 27 Jul 2010, at 10:11, Alexandre Bergel wrote:
Indeed I also want to log for each test: - min / max / mean execution time - time to first failure - % of errors/failures/success - run count
That would be cool
so with these datas we know long tests. I think about wrapping run test methods with an object which then can collect these datas. Would you go this way ? (Another way is to modify TestResult / TestCase, but it's more intrusive).
Over the last few month I intensively used method wrapper (a.k.a object as compiled method). Time to time, the image just freezes or crashes. Maybe due to the garbage collector. Modifying SUnit should not be that complex. It would be nice to turn SUnit into something more extensible. One shoot two targets.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com
"One cannot do more than one can do."
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 29.07.2010 17:45, Alexandre Bergel wrote:
Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
Cheers, Henry
On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:
On 29.07.2010 17:45, Alexandre Bergel wrote:
Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool.
I will be in winter time in 1 week time. We have to enjoy now
Alexandre
Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
+1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object. Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent. Cheers, Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
hi! In PharoInbox there is: SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.2 The comment of this slice is: -=-=-=-=-=-=-=-=-=-=-=-= Renamed the event classes into: TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded Event are also emitted in TestResult>>runCase: like this, the result of the test execution is accessible from the event. (Thanks Laurent Laffon for these suggestions) -=-=-=-=-=-=-=-=-=-=-=-= Cheers, Alexandre On 29 Jul 2010, at 22:22, laurent laffont wrote:
On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: On 29.07.2010 17:45, Alexandre Bergel wrote: Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
+1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object.
Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent.
Cheers,
Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I will integrate it. I was thinking that WindowOpened is not that english but it has the advantage that all the events of a certain kinds are grouped. Stef On Aug 2, 2010, at 12:08 PM, Alexandre Bergel wrote:
hi!
In PharoInbox there is: SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.2 The comment of this slice is: -=-=-=-=-=-=-=-=-=-=-=-= Renamed the event classes into: TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Event are also emitted in TestResult>>runCase: like this, the result of the test execution is accessible from the event. (Thanks Laurent Laffon for these suggestions) -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On 29 Jul 2010, at 22:22, laurent laffont wrote:
On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: On 29.07.2010 17:45, Alexandre Bergel wrote: Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
+1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object.
Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent.
Cheers,
Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I will integrate it. I was thinking that WindowOpened is not that english but it has the advantage that all the events of a certain kinds are grouped.
Yes, this is why I first used SUAnnouncement and SUTestBegin... Alexandre
Stef
On Aug 2, 2010, at 12:08 PM, Alexandre Bergel wrote:
hi!
In PharoInbox there is: SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.2 The comment of this slice is: -=-=-=-=-=-=-=-=-=-=-=-= Renamed the event classes into: TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Event are also emitted in TestResult>>runCase: like this, the result of the test execution is accessible from the event. (Thanks Laurent Laffon for these suggestions) -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On 29 Jul 2010, at 22:22, laurent laffont wrote:
On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: On 29.07.2010 17:45, Alexandre Bergel wrote: Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
+1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object.
Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent.
Cheers,
Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alex I integrated your changes but I tried to understand the logic behind event := anAnnouncementClass isBehavior ifTrue: [ anAnnouncementClass new ] ifFalse: [ anAnnouncementClass ]. Why anAnnouncementClass would not be a class? announce: anAnnouncementClass withResult: result | event | self shouldAnnounce ifFalse: [ ^ self ]. event := anAnnouncementClass isBehavior ifTrue: [ anAnnouncementClass new ] ifFalse: [ anAnnouncementClass ]. event testCase: self. event testSelector: testSelector. event result: result. self announcer announce: event. On Aug 2, 2010, at 12:47 PM, Stéphane Ducasse wrote:
I will integrate it. I was thinking that WindowOpened is not that english but it has the advantage that all the events of a certain kinds are grouped.
Stef
On Aug 2, 2010, at 12:08 PM, Alexandre Bergel wrote:
hi!
In PharoInbox there is: SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.2 The comment of this slice is: -=-=-=-=-=-=-=-=-=-=-=-= Renamed the event classes into: TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Event are also emitted in TestResult>>runCase: like this, the result of the test execution is accessible from the event. (Thanks Laurent Laffon for these suggestions) -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On 29 Jul 2010, at 22:22, laurent laffont wrote:
On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: On 29.07.2010 17:45, Alexandre Bergel wrote: Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
+1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object.
Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent.
Cheers,
Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
event := anAnnouncementClass isBehavior                 ifTrue: [ anAnnouncementClass new ]                 ifFalse: [  anAnnouncementClass ].
See #asAnnouncement, that does the same as the above code. Lukas -- Lukas Renggli www.lukas-renggli.ch
event := anAnnouncementClass isBehavior ifTrue: [ anAnnouncementClass new ] ifFalse: [ anAnnouncementClass ].
Why anAnnouncementClass would not be a class?
True. I wasn't sure. SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.3 in the inbox. I also use #asAnnouncement, as suggested by Lukas. Cheers, Alexandre
announce: anAnnouncementClass withResult: result | event | self shouldAnnounce ifFalse: [ ^ self ].
event := anAnnouncementClass isBehavior ifTrue: [ anAnnouncementClass new ] ifFalse: [ anAnnouncementClass ]. event testCase: self. event testSelector: testSelector. event result: result. self announcer announce: event.
On Aug 2, 2010, at 12:47 PM, Stéphane Ducasse wrote:
I will integrate it. I was thinking that WindowOpened is not that english but it has the advantage that all the events of a certain kinds are grouped.
Stef
On Aug 2, 2010, at 12:08 PM, Alexandre Bergel wrote:
hi!
In PharoInbox there is: SLICE-Issue-2721-AnnouncementsForSUnit-Alexandre_Bergel.2 The comment of this slice is: -=-=-=-=-=-=-=-=-=-=-=-= Renamed the event classes into: TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Event are also emitted in TestResult>>runCase: like this, the result of the test execution is accessible from the event. (Thanks Laurent Laffon for these suggestions) -=-=-=-=-=-=-=-=-=-=-=-=
Cheers, Alexandre
On 29 Jul 2010, at 22:22, laurent laffont wrote:
On Thu, Jul 29, 2010 at 7:42 PM, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote: On 29.07.2010 17:45, Alexandre Bergel wrote: Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
+1. I propose TestCaseAnnouncement -- TestCaseStarted -- TestCaseEnded
Shouldn't we put announce in TestResult>>runCase: instead of TestCase>>runCase ? This way we can pass the result to the Annoucement object.
Actually, self announce: SUTestEndAnnouncement. is not in the ensure: block. So if the test fails there's no annoucement sent.
Cheers,
Laurent
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Then why do you have several announcers and keep them in a classVariable? Stef
Then why do you have several announcers and keep them in a classVariable?
An alternative solution would be to have an instance variable in the meta-class. This is what I did first. But you need to recompile the more than 500 unit tests in that case to add the iv. We can go that way. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Aug 3, 2010, at 12:18 AM, Alexandre Bergel wrote:
Then why do you have several announcers and keep them in a classVariable?
An alternative solution would be to have an instance variable in the meta-class. This is what I did first. But you need to recompile the more than 500 unit tests in that case to add the iv. We can go that way.
alex my question was more naive and probably it shows that I do not know how the announce protocol should be implemented but why do you have to record them?
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
alex my question was more naive and probably it shows that I do not know how the announce protocol should be implemented but why do you have to record them?
The purpose of an announcer is to dispatch events. Callbacks are registered in an announcer, and an announcer receives and dispatch events to the callbacks. In my enh, each unit test (subclass of TestCase) has an announcer. Maybe this is not a good strategy. Having one global announcer for unit test may be more convenient in some situations. Something nice, is that if there is no callback registered, events are not emitted. This means that this should incur no overhead (even though I did not measured). Cheers, Alexandre
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Aug 3, 2010, at 2:12 PM, Alexandre Bergel wrote:
alex my question was more naive and probably it shows that I do not know how the announce protocol should be implemented but why do you have to record them?
The purpose of an announcer is to dispatch events. Callbacks are registered in an announcer, and an announcer receives and dispatch events to the callbacks. In my enh, each unit test (subclass of TestCase) has an announcer. Maybe this is not a good strategy. Having one global announcer for unit test may be more convenient in some situations.
Something nice, is that if there is no callback registered, events are not emitted. This means that this should incur no overhead (even though I did not measured).
Thanks for the explanation so I think that then this is better to have one per class this way we do not have the Dependent kind of problems where you have plenty of objects registering to a single table and get everytbody slow. Stef
Cheers, Alexandre
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Aug 3, 2010 at 2:46 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
On Aug 3, 2010, at 2:12 PM, Alexandre Bergel wrote:
alex my question was more naive and probably it shows that I do not know how the announce protocol should be implemented but why do you have to record them?
The purpose of an announcer is to dispatch events. Callbacks are registered in an announcer, and an announcer receives and dispatch events to the callbacks. In my enh, each unit test (subclass of TestCase) has an announcer. Maybe this is not a good strategy. Having one global announcer for unit test may be more convenient in some situations.
Something nice, is that if there is no callback registered, events are not emitted. This means that this should incur no overhead (even though I did not measured).
Thanks for the explanation so I think that then this is better to have one per class this way we do not have the Dependent kind of problems where you have plenty of objects registering to a single table and get everytbody slow.
I wonder, if the announcer is in TestResult, we only need one, no ? Laurent
Stef
Cheers, Alexandre
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I wonder, if the announcer is in TestResult, we only need one, no ?
Could be. But how do you register in that case? TestResult is normally instantiated in TestCase>>run and TestSuite>>run You will need to shortcut sunit then... Alexandre
Laurent
Stef
Cheers, Alexandre
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Aug 3, 2010 at 8:24 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
I wonder, if the announcer is in TestResult, we only need one, no ?
Could be. But how do you register in that case? TestResult is normally instantiated in TestCase>>run and TestSuite>>run You will need to shortcut sunit then...
I was thinking about something like: TestResult class>>announcer ^ announcer ifNil: [announcer := Announcer new] TestResult>>announce: anAnnouncement self class announcer announce: anAnnouncement. TestResult>>runCase: aTestCase | testCasePassed | testCasePassed := true. self announce: TestCaseStarted new. "set selector / class/ ..." [[aTestCase runCase] on: self class failure ....... So I can write TestResult announcer on: TestCaseStarted do: [:event | Transcript show: 'new test started']. Does it have sense ? Laurent
Alexandre
Laurent
Stef
Cheers, Alexandre
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
TestResult announcer on: TestCaseStarted do: [:event | Transcript show: 'new test started'].
Hum... I personally find unintuitive to register on the result. Why the result and not the suite or the test case? This means that there is only one announcer in the system? Anyone can provide an opinion on this point? Cheers, Alexandre
Laurent
Stef
Cheers, Alexandre
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
Someone else vote for this? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Thu, Jul 29, 2010 at 10:24 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
Someone else vote for this?
I'm experimenting with Announcers on TestResult. What do you think about this syntax ? TestResult when: TestCaseStarts do: [:event | do some stuff ]. TestResult when: TestCaseEnds do: [:event | do some stuff ]. Laurent
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
TestResult when: TestCaseStarts do: [:event | do some stuff ].
TestResult when: TestCaseEnds do: [:event | do some stuff ].
Currently, the announcer is stored in TestCase. For me, it looks more intuitive to do MyTestCase announcer on: TestCaseAnnouncement do: [:ann | ... ]. than dealing with TestResult. I am okay to move the announcer in TestResult, but that's look a bit to me. Don't you feel? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Mon, Aug 2, 2010 at 12:11 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
TestResult when: TestCaseStarts do: [:event | do some stuff ].
TestResult when: TestCaseEnds do: [:event | do some stuff ].
Currently, the announcer is stored in TestCase. For me, it looks more intuitive to do MyTestCase announcer on: TestCaseAnnouncement do: [:ann | ... ].
than dealing with TestResult.
I am okay to move the announcer in TestResult, but that's look a bit to me. Don't you feel?
I'm currently playing with annoucements in TestResult. Indeed what I want to set in the TestCaseEnded: - is the test has #pass, #failure or #error - for failure and error, store the Exception so we can now why. But until I propose something, keep the implementation which fits your needs :). Laurent
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'm currently playing with annoucements in TestResult. Indeed what I want to set in the TestCaseEnded: - is the test has #pass, #failure or #error - for failure and error, store the Exception so we can now why.
In the second version, there is hasPassed, hasFailures, hasError. It simply delegates to the testResult Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
This is a good convention. I will apply to the SystemAnnouncement I enhanced slowly. On Jul 29, 2010, at 7:42 PM, Henrik Sperre Johansen wrote:
On 29.07.2010 17:45, Alexandre Bergel wrote:
Wow ! Fast !.
That means it should be easy now to do a lot of exciting stuff. Show tests progression, errors/failures as soon as they occur, log several things, drink cocktails, meet beautiful girls ....that's really cool. I will be in winter time in 1 week time. We have to enjoy now
Alexandre Nice! Maybe it's just me, or could we not add Announcement to the end of every Announcement subclass name though? Like with the window announcement, I like them better as verbs describing the event, f.ex. someAnnouncer on: TestStarted do: [] someAnnouncer on: TestEnded send: #x to: y
Cheers, Henry
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/7/26 Alexandre Bergel <alexandre@bergel.eu>
Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
Why not split the task: make SUnit support tags (which is obviously useful for so many applications) and create some auto-tagging facilities? -- Dennis Schetinin
yes! On Jul 29, 2010, at 10:51 AM, Dennis Schetinin wrote:
2010/7/26 Alexandre Bergel <alexandre@bergel.eu> Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
Why not split the task: make SUnit support tags (which is obviously useful for so many applications) and create some auto-tagging facilities?
-- Dennis Schetinin _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Alex, Now that I've managed to use Pharo at work (youhou !!) I'm in a case where I have very long tests (selenium acceptance tests) *and* I want them to run. Ideally I also want to queue and schedule them (if a test is saved twice in a queue, run only once and put it in higher position on the queue). Solutions: - have to running modes for Autotest (normal and batch) - tagging - ? Laurent On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-=
Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-=
I guess the tweak in SUnit to identify long tests should not be that hard to implement.
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu>
wrote:
I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel < alexandre@bergel.eu> 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 < alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Sorry to answer so late. I was having few days off. I am now up and running :-)
Now that I've managed to use Pharo at work (youhou !!) I'm in a case where I have very long tests (selenium acceptance tests) *and* I want them to run. Ideally I also want to queue and schedule them (if a test is saved twice in a queue, run only once and put it in higher position on the queue).
How can a test be saved twice in a queue? If you accept twice the same method?
Solutions: - have to running modes for Autotest (normal and batch) - tagging - ?
tagging will not work I feel. We could have different modes for autotest: -exhaustive: run all the tests, including long ones -transparent: run no more than 2 short tests -test only: run the test only when I modify them Cheers, Alexandre
On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-=
Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-=
I guess the tweak in SUnit to identify long tests should not be that hard to implement.
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On Tue, Aug 10, 2010 at 2:21 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:
Sorry to answer so late. I was having few days off. I am now up and running :-)
Now that I've managed to use Pharo at work (youhou !!) I'm in a case where I have very long tests (selenium acceptance tests) *and* I want them to run. Ideally I also want to queue and schedule them (if a test is saved twice in a queue, run only once and put it in higher position on the queue).
How can a test be saved twice in a queue? If you accept twice the same method?
Actually when Autotest is running it discards all method modified event. I would like to queue these events.
Solutions: - have to running modes for Autotest (normal and batch) - tagging - ?
tagging will not work I feel. We could have different modes for autotest:
-exhaustive: run all the tests, including long ones -transparent: run no more than 2 short tests -test only: run the test only when I modify them
I think I will add an on/off switch for Autotest, sometimes I don't want it to run on debugging sessions for long tests Laurent Cheers,
Alexandre
On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre@bergel.eu>
wrote:
Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-=
Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-=
I guess the tweak in SUnit to identify long tests should not be that hard to implement.
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <
alexandre@bergel.eu> wrote:
I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel < alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel < alexandre@bergel.eu> 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 < alexandre@bergel.eu> 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 <
alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I think I will add an on/off switch for Autotest, sometimes I don't want it to run on debugging sessions for long tests
This is good. I usually open and close Autotest. But having a switch will definitely help. When it is switched off, then you can monitor the test that should be run. That will be useful. Cheers, Alexandre
Laurent
Cheers, Alexandre
On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution.
Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice.
We have -=-=-=-=-=-=-=-=-=-=-=-= TestCase class>>newTestDictionary ^ Dictionary new at: #timeStamp put: TimeStamp now; at: #passed put: Set new; at: #failures put: Set new; at: #errors put: Set new; yourself -=-=-=-=-=-=-=-=-=-=-=-=
Maybe it should be extended with -=-=-=-=-=-=-=-=-=-=-=-= at: #long put: Set new -=-=-=-=-=-=-=-=-=-=-=-=
I guess the tweak in SUnit to identify long tests should not be that hard to implement.
Cheers, Alexandre
On 26 Jul 2010, at 07:44, laurent laffont wrote:
On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre@bergel.eu> wrote: I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. However, I have to disable Autotest when the tests take time to execute.
An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2).
Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests.
How would you name the tag ? Where the implementation should go ? (TestCase ?)
Laurent.
Alexandre
On 15 Jun 2010, at 21:41, laurent laffont wrote:
Hi Alexandre,
I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback.
Cheers,
Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/
On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre@bergel.eu> wrote: Hi Laurent,
I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this?
Cheers, Alexandre
On 11 Jun 2010, at 09:02, laurent laffont wrote:
On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 <alexandre@bergel.eu> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (8)
-
Alexandre Bergel -
Dennis Schetinin -
Henrik Johansen -
Henrik Sperre Johansen
-
laurent laffont -
Lukas Renggli -
Stéphane Ducasse -
Tudor Girba