On mine too... Can't wait to try it.
Great work Hernan! Cheers, Mariano. 2010/6/3 Simon Denier <[email protected]> > > That sounds great. Clearly on my to-try list > > On 3 juin 2010, at 23:04, 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 <[email protected]> > >> 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 <[email protected]> >> >> Hello, No I dont. Who is it? >>> >>> 2010/6/3 Stéphane Ducasse <[email protected]> >>> >>> 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 <[email protected]> >>>> > >>>> > >>>> > 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 >>>> > [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 >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> 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 > > > -- > Simon > > > > > _______________________________________________ > 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
