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