[Pharo-project] About TDD and Pharo

Hernan Wilkinson hernan.wilkinson at gmail.com
Thu Jun 3 23:04:06 CEST 2010


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 <marianopeck at gmail.com>

> 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 <dionisiydk at gmail.com>
>
> Hello, No I dont. Who is it?
>>
>> 2010/6/3 Stéphane Ducasse <stephane.ducasse at inria.fr>
>>
>> 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 <sean at clipperadams.com>
>>> >
>>> >
>>> > 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
>>> > Pharo-project at lists.gforge.inria.fr
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> >
>>> > _______________________________________________
>>> > Pharo-project mailing list
>>> > Pharo-project at lists.gforge.inria.fr
>>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20100603/c73d9332/attachment.htm>


More information about the Pharo-project mailing list