About TDD and Pharo
Locked
123
123
 
|
Hi all
Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. What would be the changes that we could do support it. I know that hernan did a package for that but not I would like to have a new list of items to support it. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Today's debugger (and all pharo indeed), is extremely dependant on the mouse... I would love to do all the same with just the keyboard :(
On Wed, Jun 2, 2010 at 4:30 PM, Stéphane Ducasse <[hidden email]> wrote: Hi all _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
The problems that I would like to see Pharo address are:
- redundancies in unit tests - coverage of tests - classification of low and high levels of tests (implementation tests vs user stories) What are the tools to identify and solve this issues ? Research is needed :-) Alexandre On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: > Hi all > > Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. > What would be the changes that we could do support it. > I know that hernan did a package for that but not I would like to have a new list of items > to support it. > > Stef > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I'm thinking out load here ...
In the debugger when a DNU is raised, for speeding up the programming in "TDD mode":
Some ToDo list supported from the environment and some facility for the creation of test.
All of the above maybe just make sense in TDD mode or not =P Cheers 2010/6/2 Alexandre Bergel <[hidden email]> The problems that I would like to see Pharo address are: -- Germán Leiva [hidden email] _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
Administrator
|
In reply to this post by Stéphane Ducasse
Coming from Ruby, it seemed like BDD was taking over the world, and was the next step in TDD evolution, but I found few mentions of it in the Squeak world. For my own projects, I use SSpec (which I have been fixing as I go along). I only use "tests" with SUnit assertions for community projects, as not to confuse or add additional dependencies. I think that core BDD support would be necessary to woo developers here, especially from Ruby, where all the passion and conversation is around BDD. Sean
Cheers,
Sean |
|
|
I use Mockery - my implementation SSpec idies. It is realy more powerfull, transparency and flexibility.
With Mockery you dont need any special base classes for TestCases or mocks factory variables in code. You just use mocks where you want by Block creation scenarios: [:mock | [sut doWith: mock] should lenient satisfy: [mock someMessage willReturn: #result] ] runScenario. State specs like "5 should be an instance of: Integer" can be easely added by pragmas. And Its work in Pharo 1.0. Of course, It's needs more good stuff. But now I dont have enough time. http://www.squeaksource.com/Mocketry.html 2010/6/3 Sean P. DeNigris <[hidden email]>
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Germán Leiva
On Jun 2, 2010, at 11:22 PM, Germán Leiva wrote: > I'm thinking out load here ... > > In the debugger when a DNU is raised, for speeding up the programming in "TDD mode": > • The create button must add the method in the class of the receiver, the possibility to choose a superclass of the receiver must be optional (I don't like the recurrent asking...) in other button for example or having different shortcuts from the keyboard is it not already the case? > • If I send a message that I already know that will be a getter, some option like "Create getter" could automagically create the method and the instance variable. > • When we a accept a method for the first time the pop-ups saying "Unkown selector please confirm, select or cancel" are really annoying and decrease coding speed > • Same for the category pop-ups > • In the creation of a new class through "define new class" it will be helpful to remember the last class category used > Some ToDo list supported from the environment and some facility for the creation of test. > > All of the above maybe just make sense in TDD mode or not =P if you have code I would be really interested. I know hernan did some extensions in the past > > Cheers > > 2010/6/2 Alexandre Bergel <[hidden email]> > The problems that I would like to see Pharo address are: > - redundancies in unit tests > - coverage of tests > - classification of low and high levels of tests (implementation tests vs user stories) > > What are the tools to identify and solve this issues ? Research is needed :-) > > Alexandre > > > > On 2 Jun 2010, at 15:30, Stéphane Ducasse wrote: > > > Hi all > > > > Imagine that we would like to sell pharo (+ seaside) as THE agile platform for doing TDD. > > What would be the changes that we could do support it. > > I know that hernan did a package for that but not I would like to have a new list of items > > to support it. > > > > Stef > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Germán Leiva > [hidden email] > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Sean P. DeNigris
On Jun 2, 2010, at 11:40 PM, Sean P. DeNigris wrote: > > > Stéphane Ducasse wrote: >> >> Imagine that we would like to sell pharo (+ seaside) as THE agile platform >> for doing TDD. >> What would be the changes that we could do support it. >> > > Coming from Ruby, it seemed like BDD was taking over the world, and was the > next step in TDD evolution, but I found few mentions of it in the Squeak > world. For my own projects, I use SSpec (which I have been fixing as I go > along). I only use "tests" with SUnit assertions for community projects, as > not to confuse or add additional dependencies. > > I think that core BDD support would be necessary to woo developers here, > especially from Ruby, where all the passion and conversation is around BDD. but is it not just using SSpec? Did SSpec still loads? Does it load in pharo well? Where is it? Stef > > Sean > -- > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2240877.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Denis Kudriashov
do you happen to know tim mckinnon?
Stef On Jun 3, 2010, at 12:13 AM, Denis Kudriashov wrote: > I use Mockery - my implementation SSpec idies. It is realy more powerfull, transparency and flexibility. > > With Mockery you dont need any special base classes for TestCases or mocks factory variables in code. You just use mocks where you want by Block creation scenarios: > > [:mock | > [sut doWith: mock] should lenient satisfy: [mock someMessage willReturn: #result] > ] runScenario. > > State specs like "5 should be an instance of: Integer" can be easely added by pragmas. > > And Its work in Pharo 1.0. > > Of course, It's needs more good stuff. But now I dont have enough time. > http://www.squeaksource.com/Mocketry.html > > 2010/6/3 Sean P. DeNigris <[hidden email]> > > > Stéphane Ducasse wrote: > > > > Imagine that we would like to sell pharo (+ seaside) as THE agile platform > > for doing TDD. > > What would be the changes that we could do support it. > > > > Coming from Ruby, it seemed like BDD was taking over the world, and was the > next step in TDD evolution, but I found few mentions of it in the Squeak > world. For my own projects, I use SSpec (which I have been fixing as I go > along). I only use "tests" with SUnit assertions for community projects, as > not to confuse or add additional dependencies. > > I think that core BDD support would be necessary to woo developers here, > especially from Ruby, where all the passion and conversation is around BDD. > > Sean > -- > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2240877.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Sean P. DeNigris
what is important for me is that we distinguish what is related to the UI flow from the loading of a specific
tests libraries. RIght now I would like to concentrate on UI flow and tools interaction. Stef On Jun 2, 2010, at 11:40 PM, Sean P. DeNigris wrote: > > > Stéphane Ducasse wrote: >> >> Imagine that we would like to sell pharo (+ seaside) as THE agile platform >> for doing TDD. >> What would be the changes that we could do support it. >> > > Coming from Ruby, it seemed like BDD was taking over the world, and was the > next step in TDD evolution, but I found few mentions of it in the Squeak > world. For my own projects, I use SSpec (which I have been fixing as I go > along). I only use "tests" with SUnit assertions for community projects, as > not to confuse or add additional dependencies. > > I think that core BDD support would be necessary to woo developers here, > especially from Ruby, where all the passion and conversation is around BDD. > > Sean > -- > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2240877.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
In ruby world the tools I like most for TDD are:
- autotest: when you save a file, autotest detects it are run automatically associated unit tests. http://ph7spot.com/musings/getting-started-with-autotest. For PHPUnit there's a light autotest-like http://gist.github.com/287950. I really like it as you have a smooth workflow, don't think about which test to run, quick feedback. Brings lot of confidence.
- shoulda: macros, contexts and understandable tests. http://github.com/thoughtbot/shoulda. Laurent Laffont
http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/ On Wed, Jun 2, 2010 at 9:30 PM, Stéphane Ducasse <[hidden email]> wrote: Hi all _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
Hello, No I dont. Who is it?
2010/6/3 Stéphane Ducasse <[hidden email]> do you happen to know tim mckinnon? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About TDD and Pharo
|
|
What Hernán did is here: http://www.squeaksource.com/TDDFacilities.html
That was for Pharo 1.0. For those that want to help in this subject I think the first step could be to load such package in a PharoCore1.1 and fix it in case it doesn't work. Then, it can be integrated as part of PharoCore. Although it may be cool to have a preference to enable or disable all this changes (more TDD oriented), as we are not doing TDD all the time and sometimes we want the normal behavior. Once we have that, we can start improving. For example, I would love also what Guille said: key bindings for the debugger. I would LOVE to have a Pharo less mouse oriented (I don't care who invented the mouse, I rather the keyboard). So..open a bug ticket and start to play. Cheers Mariano 2010/6/3 Denis Kudriashov <[hidden email]> Hello, No I dont. Who is it? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: About TDD and Pharo
|
|
In reply to this post by Germán Leiva
2010/6/2 Germán Leiva <[hidden email]> I'm thinking out load here ... Germán, these are cool ideas. Some of them I think they are in the Hernán package. It would be greate to check which features does it have, and create (and code!) a list of new features, like this ones.
Yes, open a ticket and put the list. I would like you can code on this also but I guess you are busy with GSoC ;)
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
Administrator
|
In reply to this post by Stéphane Ducasse
SSpec is not bad, but needs some work. It loads, but most of the tests fail - even though the project itself mostly works. It definitely works in 1.0. I don't remember if I loaded it in 1.1, I'll try when I get a minute. SqS. I will upload my fixes soon. Sean
Cheers,
Sean |
|
Administrator
|
In reply to this post by Stéphane Ducasse
Oh, okay - got it. In that case: +1 for autotest-like functionality, where appropriate tests are run when code is saved (I haven't thought through how it could work, but it sounds great; maybe run tests that are senders of the saved method?) Sean
Cheers,
Sean |
|
|
On 3 juin 2010, at 14:24, Sean P. DeNigris wrote: > > > Stéphane Ducasse wrote: >> >> what is important for me is that we distinguish what is related to the UI >> flow from the loading of a specific >> tests libraries. >> RIght now I would like to concentrate on UI flow and tools interaction. >> > > Oh, okay - got it. In that case: > +1 for autotest-like functionality, where appropriate tests are run when > code is saved (I haven't thought through how it could work, but it sounds > great; maybe run tests that are senders of the saved method?) 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. -- Simon _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
> 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? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <[hidden email]> wrote:
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
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
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 <[hidden email]> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |