About TDD and Pharo
Locked
123
123
 
|
Name: OB-SUnitIntegration-lr.30
Author: lr Time: 4 June 2010, 1:24:05 pm UUID: cc0a4ad4-3efc-4dbc-8e44-0dc27e9d5f57 Ancestors: OB-SUnitIntegration-lr.29 - say 'run test' (singular) if there is a single test selected 2010/6/4 Mariano Martinez Peck <[hidden email]>: > > > On Fri, Jun 4, 2010 at 10:40 AM, Lukas Renggli <[hidden email]> wrote: >> >> >> > 1) When you are in the browser writing a test method, you can press >> >> > ctrl >> >> > + t >> >> > to save the method and run the test. If the test runs, it will show >> >> > the >> >> > green dot in the browser, if it does not, it popups the debugger >> >> > directly on >> >> > the error. So, this is a way to avoid pressing ctrl + s (save) then >> >> > going to >> >> > the method list, rigth click an select run test and if it fails >> >> > select >> >> > that >> >> > you want to debug it. >> >> >> >> Ctrl+T does not save, but it runs the tests and shows the debugger. I >> >> don't think that I like the two things to be combined :-) >> > >> > That's what I don't like, ctrl + t runs all the tests of the class, not >> > only >> > the method were you are. >> >> No, this is not the case. > > Ups...spoke faster than speaking. It's true, Pharo 1.1 with the latests OB > it works as expected. > Can we just change the label "run tests" to "run test" ? > > Thanks lukas > > mariano > > >> >> > This was discussed with Adrian Kuhn and he integrated this change in his >> > package. I don't know where is it neither if it was integrated or not. >> >> Yes, I integrated that a year ago or so :-) >> >> Lukas >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> 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 > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernan.wilkinson
> I have some questions... if you are writting a test in the browser and want
> to run it (just test), if you press ctr+t, does it run that test or all the > tests? and also, if it does not save the method, how does it run the test > you just wrote ? It runs just the selected test method. If you have not accepted the change it runs the old compiled code (as it would for a do-it). > I did the ctrl+t do the save before running because I found myself saving > then running, saving then running, etc, all the time... and if you want to > run the test you have to save it before... why do you think you would not > like the two things combined? do you see something that could bother or be > wrong about it? Consistency with the rest of the browser and separation of concerns. But, I haven't tried your approach so I cannot really tell what is better. Jorge demoed your debugger changes (create class, create method). I would like to see them in PharoCore. Also I would like to get rid of the pre-debugger all-together. Do you think that you could provide these changes in the PharoInbox? Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ 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
he implemented Mockery for dolphin I guess and he is in pharo mailing-list probably flooded by mails :)
On Jun 3, 2010, at 9:06 AM, Denis Kudriashov wrote: > Hello, No I dont. Who is it? > > 2010/6/3 Stéphane Ducasse <[hidden email]> > 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 > > _______________________________________________ > 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 Mariano Martinez Peck
Just pay attention that I already integrated some changes of Hernan (like the warning for the compiler).
Stef On Jun 3, 2010, at 9:29 AM, Mariano Martinez Peck wrote: > 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? > > 2010/6/3 Stéphane Ducasse <[hidden email]> > > 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 > > > _______________________________________________ > 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
I know that keith integrated SSpec and SUnit so probably there are enhancements there.
Stef On Jun 3, 2010, at 2:16 PM, Sean P. DeNigris wrote: > > > Stéphane Ducasse wrote: >> >> but is it not just using SSpec? >> > SSpec is not bad, but needs some work. > > > Stéphane Ducasse wrote: >> >> Did SSpec still loads? >> > It loads, but most of the tests fail - even though the project itself mostly > works. > > > Stéphane Ducasse wrote: >> >> Does it load in pharo well? >> > 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. > > > Stéphane Ducasse wrote: >> >> Where is it? >> > SqS. I will upload my fixes soon. > > Sean > -- > View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2241568.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 Lukas Renggli
On Jun 3, 2010, at 9:13 PM, Lukas Renggli wrote: >> -Suggest to delete accessors when deleting an IV > > You cannot delete an inst-var with the refactoring engine if there are > references. but lukas you can pipe them. first remove the iv second ask for removing accessors > >> -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) > > This is built-in for several years now: refactor class | create accessors > >> -Have a preference that automatically generate accessors on addition of IVs / class definition > > I rarely use these accessor refactorings because I have to rewrite > each method by hand afterwards anyway to have a type-revealing > argument name and a comment. > > Lukas > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > 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 hernan.wilkinson
hernan can you chop that into simple but entry as request for improvement?
Stef On Jun 3, 2010, at 11:04 PM, Hernan Wilkinson wrote: > Hi all, > this is a cool thread! :-) > > What I did are changes to the tools to make more easy to run tests and implement what is needed. For example: > > 1) When you are in the browser writing a test method, you can press ctrl + t to save the method and run the test. If the test runs, it will show the green dot in the browser, if it does not, it popups the debugger directly on the error. So, this is a way to avoid pressing ctrl + s (save) then going to the method list, rigth click an select run test and if it fails select that you want to debug it. > I think this is really useful > 2) Same as ctrl + t but ctrl + r to directly debug the test. It saves the method, puts a breakpoint in it and debugs it. Unfortunaly, in Pharo breakpoints dont show very well in the debuger (it highlights incorrect collaborations) > 3) I removed the Notifier window, it directly opens the debugger > 4) The debugger opens as a big window (so you dont have to resize it every time a test fails that is most of the time when doing tdd) > 5) The debugger has an "Implement" button that does what German Lieva suggested > 6) Removed all the questions the browser ask when saving a method that sends a message not implemented, etc. I left defined not declared class and variables. > > I think there are more things that could be improved/implemented: > 1) Provide a default implementation for methods that look like getter or setters (like German also suggested. VisualAge does that very nice) > 2) Allow the "Implement" option to work also when the method has a "subclassResponsibility" Right now it only works with "DoesNotUnderstand" > 3) Allow to define coding patterns easily and execute those coding patterns automatically when needed. For example, I have coding pattern form instance creation messages like this: > Attendee named: aName attending: aCollectionOfDates > > ^ self new initializeNamed: aName attending: aCollectionOfDates > > It send the message new and the initializeXxx where Xxx is the same name of the instance creation message > We could provide default implementation for well know messages like #= or #hash (but this requires to generalize the implementation of #= and #hash using other objets...) > 4) Similar to the previous one but for classes. For example if I write: > InvalidNameException signalName: xxx > It could be inferred that we are creating an Exception, that the exception will have a class message that will signal the exception and an instance creation message (#name:) to create instances, and an initialization message (#initializeName:) and an instance variable called name. > (Of course one could argue that if this can be automatize, the we can create an abstraction for that and then we would not need a class per exception... but that is another discussion :-) ) > 5) Change how the categorization of a method works. It should suggest a category based on the automatic categorization and it should not show so many options as it does right now (it is really annoying to see so many options) > 6) Change the dialog for creating a class, it is too small > > I think that using TDD or BDD is another discussion... (for me there is no much different, that depends on what you understand with TDD...) > I don't know if I'd like the test to run automatically, never tried it, but it looks to me that it could be distractive... > > Bye > Hernan > > > 2010/6/3 Mariano Martinez Peck <[hidden email]> > 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? > > 2010/6/3 Stéphane Ducasse <[hidden email]> > > 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 > > > _______________________________________________ > 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 _______________________________________________ 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
Thanks Steph, I had checked the Testing project before and its latest timestamp for SSpec is a few years earlier, so I think the SSpec repo has the best version. But it seems that project was in line with what I was suggesting - to have BDD tools together with the TDD tools. Sean
Cheers,
Sean |
|
|
In reply to this post by Germán Leiva
I think the rationale must be: during TDD it's ok to ask the developer
questions that he can answer right away. Thus, it's ok that the create button asks for the class: you know instantly what to answer. But asking for the method category is a major pain. I don't know about y'all, but I never quite know upfront how I'll structure my categories. That emerges much later in the process. In short: remove the asking for the method category. Just put it in 'not yet categorized', and have me figure it out later. Cheers, Niko 2010/6/2 Germán Leiva <[hidden email]>: > 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 > 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 > 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 > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
it is true, I almost all the time cancel that dialog to put the method as not yet categorized... but sometimes I select the category... I think that pressing ESC or cancel is not that bad in this case and I would keep this dialog.
On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz <[hidden email]> wrote: I think the rationale must be: during TDD it's ok to ask the developer _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Yes but the list should be shorter. Maybe only showing the class categories and what I've previously entered since I opened the image. And not all the hierarchy categories.
Cheers, Mariano. 2010/6/7 Hernan Wilkinson <[hidden email]> it is true, I almost all the time cancel that dialog to put the method as not yet categorized... but sometimes I select the category... I think that pressing ESC or cancel is not that bad in this case and I would keep this dialog. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by hernan.wilkinson
Right, only that I'm unhappy with the naming. I'd never have guessed
that "cancel" does what I want. So far, I've always chosen a random junk category and fixed it up later. A button "Cancel" I'd expect to cancel the creation altogether. Niko 2010/6/7 Hernan Wilkinson <[hidden email]>: > it is true, I almost all the time cancel that dialog to put the method as > not yet categorized... but sometimes I select the category... I think that > pressing ESC or cancel is not that bad in this case and I would keep this > dialog. > > On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz <[hidden email]> > wrote: >> >> I think the rationale must be: during TDD it's ok to ask the developer >> questions that he can answer right away. Thus, it's ok that the create >> button asks for the class: you know instantly what to answer. But >> asking for the method category is a major pain. I don't know about >> y'all, but I never quite know upfront how I'll structure my >> categories. That emerges much later in the process. >> >> In short: remove the asking for the method category. Just put it in >> 'not yet categorized', and have me figure it out later. >> >> Cheers, >> >> Niko >> >> 2010/6/2 Germán Leiva <[hidden email]>: >> > 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 >> > 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 >> > 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 >> > >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> 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 > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
True, that happened to me too... Until I wanted to cancel the creation, and then I realized... It's a really bad name.
Cheers, Mariano. On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <[hidden email]> wrote: Right, only that I'm unhappy with the naming. I'd never have guessed _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by niko.schwarz
maybe the right name would be something like "don´t categorize" ;)
On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <[hidden email]> wrote: Right, only that I'm unhappy with the naming. I'd never have guessed _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Why not offer "not yet categorized" as the first option as a category
to choose from? Niko 2010/6/7 Gabriel Brunstein <[hidden email]>: > maybe the right name would be something like "don´t categorize" ;) > > On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <[hidden email]> > wrote: >> >> Right, only that I'm unhappy with the naming. I'd never have guessed >> that "cancel" does what I want. So far, I've always chosen a random >> junk category and fixed it up later. A button "Cancel" I'd expect to >> cancel the creation altogether. >> >> Niko >> >> 2010/6/7 Hernan Wilkinson <[hidden email]>: >> > it is true, I almost all the time cancel that dialog to put the method >> > as >> > not yet categorized... but sometimes I select the category... I think >> > that >> > pressing ESC or cancel is not that bad in this case and I would keep >> > this >> > dialog. >> > >> > On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz >> > <[hidden email]> >> > wrote: >> >> >> >> I think the rationale must be: during TDD it's ok to ask the developer >> >> questions that he can answer right away. Thus, it's ok that the create >> >> button asks for the class: you know instantly what to answer. But >> >> asking for the method category is a major pain. I don't know about >> >> y'all, but I never quite know upfront how I'll structure my >> >> categories. That emerges much later in the process. >> >> >> >> In short: remove the asking for the method category. Just put it in >> >> 'not yet categorized', and have me figure it out later. >> >> >> >> Cheers, >> >> >> >> Niko >> >> >> >> 2010/6/2 Germán Leiva <[hidden email]>: >> >> > 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 >> >> > 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 >> >> > 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 >> >> > >> >> >> >> >> >> >> >> -- >> >> http://scg.unibe.ch/staff/Schwarz >> >> twitter.com/nes1983 >> >> Tel: +41 076 235 8683 >> >> >> >> _______________________________________________ >> >> 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 >> > >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> 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 > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
I listed this behavior as http://code.google.com/p/pharo/issues/detail?id=2522
Cheers, Niko On Mon, Jun 7, 2010 at 10:04 PM, Niko Schwarz <[hidden email]> wrote: > Why not offer "not yet categorized" as the first option as a category > to choose from? > > Niko > > 2010/6/7 Gabriel Brunstein <[hidden email]>: >> maybe the right name would be something like "don´t categorize" ;) >> >> On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <[hidden email]> >> wrote: >>> >>> Right, only that I'm unhappy with the naming. I'd never have guessed >>> that "cancel" does what I want. So far, I've always chosen a random >>> junk category and fixed it up later. A button "Cancel" I'd expect to >>> cancel the creation altogether. >>> >>> Niko >>> >>> 2010/6/7 Hernan Wilkinson <[hidden email]>: >>> > it is true, I almost all the time cancel that dialog to put the method >>> > as >>> > not yet categorized... but sometimes I select the category... I think >>> > that >>> > pressing ESC or cancel is not that bad in this case and I would keep >>> > this >>> > dialog. >>> > >>> > On Mon, Jun 7, 2010 at 5:45 AM, Niko Schwarz >>> > <[hidden email]> >>> > wrote: >>> >> >>> >> I think the rationale must be: during TDD it's ok to ask the developer >>> >> questions that he can answer right away. Thus, it's ok that the create >>> >> button asks for the class: you know instantly what to answer. But >>> >> asking for the method category is a major pain. I don't know about >>> >> y'all, but I never quite know upfront how I'll structure my >>> >> categories. That emerges much later in the process. >>> >> >>> >> In short: remove the asking for the method category. Just put it in >>> >> 'not yet categorized', and have me figure it out later. >>> >> >>> >> Cheers, >>> >> >>> >> Niko >>> >> >>> >> 2010/6/2 Germán Leiva <[hidden email]>: >>> >> > 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 >>> >> > 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 >>> >> > 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 >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> http://scg.unibe.ch/staff/Schwarz >>> >> twitter.com/nes1983 >>> >> Tel: +41 076 235 8683 >>> >> >>> >> _______________________________________________ >>> >> 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 >>> > >>> >>> >>> >>> -- >>> http://scg.unibe.ch/staff/Schwarz >>> twitter.com/nes1983 >>> Tel: +41 076 235 8683 >>> >>> _______________________________________________ >>> 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 >> > > > > -- > http://scg.unibe.ch/staff/Schwarz > twitter.com/nes1983 > Tel: +41 076 235 8683 > -- http://scg.unibe.ch/staff/Schwarz twitter.com/nes1983 Tel: +41 076 235 8683 _______________________________________________ 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 |