Hi Doru! if you are asking about the package I wrote, just install the latest version of TDDFacilities on a pharo 1.0 image and then evaluate: OBTextMorphEditorWithShout initialize
Bye!, Hernan. On Thu, Jun 3, 2010 at 5:39 PM, Tudor Girba <[email protected]> wrote: > The list is quite promising. > > How exactly do I load it? > > Cheers, > Doru > > > > On 3 Jun 2010, at 23:34, Mariano Abel Coca wrote: > > 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 >> > > -- > www.tudorgirba.com > > "We are all great at making mistakes." > > > > > > > > _______________________________________________ > 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
