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 <[email protected]>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 <[email protected]>: > > 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 <[email protected]> > >> > >> 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 > >> > [email protected] > >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [email protected] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > -- > > Germán Leiva > > [email protected] > > > > _______________________________________________ > > Pharo-project mailing list > > [email protected] > > 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 > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
