Where should I look? :D Is something written somewhere? :P On Thu, Jun 3, 2010 at 1:22 PM, Stéphane Ducasse <Stephane.Ducasse@inria.fr>wrote:

On Jun 2, 2010, at 10:42 PM, Guillermo Polito wrote:

...

Today's debugger (and all pharo indeed), is extremely dependant on the mouse... I would love to do all the same with just the keyboard :(

me too. Now if you want to help in this direction we should check the packages for keybindings and see what they are doing and how we could integrate them. The way this is done in the paragraph editor is not good. I spent hours on it for the botsinc book long time ago.

Stef

...

On Wed, Jun 2, 2010 at 4:30 PM, Stéphane Ducasse <

stephane.ducasse@inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <alexandre.bergel@inria.fr>

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Germán Leiva LeivaGerman@gmail.com

On 3 juin 2010, at 07:45, Stéphane Ducasse wrote:

On Jun 2, 2010, at 11:22 PM, Germán Leiva wrote:

...

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 is it not already the case?

Only when the exception window shows up. Once you click on the debug button, you can't do it anymore.

...

• 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.

I'd rather go for a bit more sophisticated system based on Scrum task board coupled with Monticello. Tasks descriptions are organized in three collections Done, ToDo and inProgress. Once we do a project snapshot, we got these descriptions referenced in the snapshot. So, when browsing the history of snapshot, one can more easily figure out what each version is about. More features I'd like to have is in the refactoring browser : -When renaming an instance variable, rename its accessors two -Suggest to delete accessors when deleting an IV -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) -Have a preference that automatically generate accessors on addition of IVs / class definition Noury

On Jun 3, 2010, at 9:13 PM, Lukas Renggli wrote:

...

-Suggest to delete accessors when deleting an IV

You cannot delete an inst-var with the refactoring engine if there are references.

but lukas you can pipe them. first remove the iv second ask for removing accessors

...

-Be able to generate accessors for multiple IVs at the same time (like in eclipse!)

This is built-in for several years now: refactor class | create accessors

...

-Have a preference that automatically generate accessors on addition of IVs / class definition

I rarely use these accessor refactorings because I have to rewrite each method by hand afterwards anyway to have a type-revealing argument name and a comment.

Lukas

-- Lukas Renggli www.lukas-renggli.ch

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

We run the lint tests (and other we wrote like "are the visitor patterns implemented correctly?", "is the code you wrote following the design and coding conventions?" etc. before sending the package to integrate of making a new version of it... When doing tdd, having all test green does not mean you are done with the development and I think those type of test have to be run when development is done... On Thu, Jun 3, 2010 at 3:41 PM, Noury Bouraqadi <bouraqadi@gmail.com> wrote:

I'd like to add to my whishlist : an automated execution of lint when all tests are green.

Noury On 3 juin 2010, at 21:07, Noury Bouraqadi wrote:

...

On 3 juin 2010, at 07:45, Stéphane Ducasse wrote:

...

On Jun 2, 2010, at 11:22 PM, Germán Leiva wrote:

...

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 is it not already the case?

Only when the exception window shows up. Once you click on the debug button, you can't do it anymore.

...

...

• 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.

I'd rather go for a bit more sophisticated system based on Scrum task board coupled with Monticello. Tasks descriptions are organized in three collections Done, ToDo and inProgress. Once we do a project snapshot, we got these descriptions referenced in the snapshot. So, when browsing the history of snapshot, one can more easily figure out what each version is about.

More features I'd like to have is in the refactoring browser : -When renaming an instance variable, rename its accessors two -Suggest to delete accessors when deleting an IV -Be able to generate accessors for multiple IVs at the same time (like in eclipse!) -Have a preference that automatically generate accessors on addition of IVs / class definition

Noury

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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 <leivagerman@gmail.com>:

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 <alexandre.bergel@inria.fr>

...

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Germán Leiva LeivaGerman@gmail.com

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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

Yes but the list should be shorter. Maybe only showing the class categories and what I've previously entered since I opened the image. And not all the hierarchy categories. Cheers, Mariano. 2010/6/7 Hernan Wilkinson <hernan.wilkinson@gmail.com>

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 <niko.schwarz@googlemail.com>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 <leivagerman@gmail.com>:

...

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 <alexandre.bergel@inria.fr>

...

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Germán Leiva LeivaGerman@gmail.com

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

True, that happened to me too... Until I wanted to cancel the creation, and then I realized... It's a really bad name. Cheers, Mariano. On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <niko.schwarz@googlemail.com>wrote:

Right, only that I'm unhappy with the naming. I'd never have guessed that "cancel" does what I want. So far, I've always chosen a random junk category and fixed it up later. A button "Cancel" I'd expect to cancel the creation altogether.

Niko

2010/6/7 Hernan Wilkinson <hernan.wilkinson@gmail.com>:

...

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 < niko.schwarz@googlemail.com> 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 <leivagerman@gmail.com>:

...

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 <alexandre.bergel@inria.fr>

...

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 Pharo-project@lists.gforge.inria.fr

http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Germán Leiva LeivaGerman@gmail.com

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

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

Why not offer "not yet categorized" as the first option as a category to choose from? Niko 2010/6/7 Gabriel Brunstein <gaboto@gmail.com>:

maybe the right name would be something like "don´t categorize"  ;)

On Mon, Jun 7, 2010 at 11:54 AM, Niko Schwarz <niko.schwarz@googlemail.com> wrote:

...

Right, only that I'm unhappy with the naming. I'd never have guessed that "cancel" does what I want. So far, I've always chosen a random junk category and fixed it up later. A button "Cancel" I'd expect to cancel the creation altogether.

Niko

2010/6/7 Hernan Wilkinson <hernan.wilkinson@gmail.com>:

...

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 <niko.schwarz@googlemail.com> 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 <leivagerman@gmail.com>:

...

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 <alexandre.bergel@inria.fr>

...

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 Pharo-project@lists.gforge.inria.fr

http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Germán Leiva LeivaGerman@gmail.com

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

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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

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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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@gmail.com>

Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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

Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

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 <Simon.Denier@inria.fr>

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

Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- www.tudorgirba.com "We are all great at making mistakes."

more thoughts about this... I think that the Smalltalk debugger is the best tool we have, the tool that allow us to be really "dynamic" (or agile, depending on the buzz you like the most :-)) and that we should take more advantage of when doing tdd (and not only tdd). People used to use other languages can not believe things we do in the debugger like implementing methods while running the tests, creating classes, adding inst vars, retrying contexts, etc. Basically what I'm saying is that when you are doing tdd, the real programming happens on the debugger, so taking advantage of the execution context is something we can improve on the debugger... make the debugger not only a debugging tool but a programming tool. For example, ocompletion could take advantage of that, is you want to send a message to an object referenced by a variable, ocompletion could show only the messages that object understands, of if you write "aCollection size " then it could suggest messages that an integer understand (I'm assuming aCollection is a collection :-) ) This last idea could generate "second effects", so having a "transactional image" could help to avoid that... We should think about other things that we could improve on the debugger having real objects and not just text... other crazy/not so sure ideas: 1) when writing a printOn: message, I always see how the contents of the stream ends up being... we could see that directly moving the mouse over the stream variable for example, like a quick preview 2) when sending a select: or detect: or reject: or do: etc message, it could take one element of the collection to infer the messages we can send to the block parameter 3) when an exception is signal, we could select a context and say, "Help me implement the handler" and therefore the debugger adds the [ ] around the selected code and puts the "on: theRealExceptionClass do: [ :....]" (where theRealExceptonClass is the class of the exception not handled and it knows it because it was just signaled" I think the pattern to follow and discover other things we could improve are: "What do you have to think, to try on your mind, when you are programming in the debugger?"... then see if those things you "try" in your mind can be done by the debugger... I think this could lead us to un-think tools yet On Thu, Jun 3, 2010 at 5:04 PM, Hernan Wilkinson <hernan.wilkinson@gmail.com

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

Hello, No I dont. Who is it?

...

2010/6/3 Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I've been using TDDFacilities in Pharo since it was first released. It is precisely what I needed to achieve real TDD while developing my tools. New features in the New Compiler and TextLint (from scratch) were developed using this tool. Doru, if you want I can give you a short demo of it. I think that what Hernan is proposing is very important. The debugger is the tool that TDD developers use the most, we should concentrate on it first and then try to find out other potential improvements in other tools. I think we should invest some time into this. Cheers, Jorge On Fri, Jun 4, 2010 at 7:36 AM, Lukas Renggli <renggli@gmail.com> wrote:

OBSUnitIntegration is already providing some of those:

...

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.

Ctrl+T does not save, but it runs the tests and shows the debugger. I don't think that I like the two things to be combined :-)

...

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)

Ctrl+D opens a full debugger on the first line of the selected test, no matter if the test fails or not. It doesn't use breakpoints. And I use it all the time :-)

So maybe we could combine some of that code?

Lukas

-- Lukas Renggli www.lukas-renggli.ch

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Fri, Jun 4, 2010 at 7:36 AM, Lukas Renggli <renggli@gmail.com> wrote:

> OBSUnitIntegration is already providing some of those:
>
> > 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.
>
> Ctrl+T does not save, but it runs the tests and shows the debugger. I
> don't think that I like the two things to be combined :-)
>
>
That's what I don't like, ctrl + t runs all the tests of the class, not only
the method were you are.
I would love ctrl + t to run only the test where I am and if I want to run
all the test of the class, then I select the class and then ctrl + t.

This was discussed with Adrian Kuhn and he integrated this change in his
package. I don't know where is it neither if it was integrated or not.

Cheers

Mariano



> > 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)
>
> Ctrl+D opens a full debugger on the first line of the selected test,
> no matter if the test fails or not. It doesn't use breakpoints. And I
> use it all the time :-)
>
> So maybe we could combine some of that code?
>
> Lukas
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

On Fri, Jun 4, 2010 at 10:40 AM, Lukas Renggli <renggli@gmail.com> wrote:

...

...

...

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.

Ctrl+T does not save, but it runs the tests and shows the debugger. I don't think that I like the two things to be combined :-)

That's what I don't like, ctrl + t runs all the tests of the class, not only the method were you are.

No, this is not the case.

Ups...spoke faster than speaking. It's true, Pharo 1.1 with the latests OB it works as expected. Can we just change the label "run tests" to "run test" ? Thanks lukas mariano

...

This was discussed with Adrian Kuhn and he integrated this change in his package. I don't know where is it neither if it was integrated or not.

Yes, I integrated that a year ago or so :-)

Lukas

-- Lukas Renggli www.lukas-renggli.ch

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

cool! I did not know about it...
I have some questions... if you are writting a test in the browser and want
to run it (just test), if you press ctr+t, does it run that test or all the
tests? and also, if it does not save the method, how does it run the test
you just wrote ?

I did the ctrl+t do the save before running because I found myself saving
then running, saving then running, etc, all the time... and if you want to
run the test you have to save it before... why do you think you would not
like the two things combined? do you see something that could bother or be
wrong about it?



On Fri, Jun 4, 2010 at 1:36 AM, Lukas Renggli <renggli@gmail.com> wrote:

> OBSUnitIntegration is already providing some of those:
>
> > 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.
>
> Ctrl+T does not save, but it runs the tests and shows the debugger. I
> don't think that I like the two things to be combined :-)
>
> > 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)
>
> Ctrl+D opens a full debugger on the first line of the selected test,
> no matter if the test fails or not. It doesn't use breakpoints. And I
> use it all the time :-)
>
> So maybe we could combine some of that code?
>
> Lukas
>
>
> --
> Lukas Renggli
> www.lukas-renggli.ch
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

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

Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Tim Mckinnon is creator SMock for Dolphin. I see his work. And his work will be stimul for me to implement mock-famework in VW and squeak (that I used) with more user friendly and powerfull features. 2010/6/3 Denis Kudriashov <dionisiydk@gmail.com>

Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <stephane.ducasse@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Jun 2, 2010, at 11:40 PM, Sean P. DeNigris wrote:

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.

but is it not just using SSpec? Did SSpec still loads? Does it load in pharo well? Where is it? Stef

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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

I know that keith integrated SSpec and SUnit so probably there are enhancements there. Stef On Jun 3, 2010, at 2:16 PM, Sean P. DeNigris wrote:

Stéphane Ducasse wrote:

...

but is it not just using SSpec?

SSpec is not bad, but needs some work.

Stéphane Ducasse wrote:

...

Did SSpec still loads?

It loads, but most of the tests fail - even though the project itself mostly works.

Stéphane Ducasse wrote:

...

Does it load in pharo well?

It definitely works in 1.0. I don't remember if I loaded it in 1.1, I'll try when I get a minute.

Stéphane Ducasse wrote:

...

Where is it?

SqS. I will upload my fixes soon.

Sean -- View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2241568.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

what is important for me is that we distinguish what is related to the UI flow from the loading of a specific tests libraries. RIght now I would like to concentrate on UI flow and tools interaction. Stef On Jun 2, 2010, at 11:40 PM, Sean P. DeNigris wrote:

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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 3 juin 2010, at 14:24, Sean P. DeNigris wrote:

Stéphane Ducasse wrote:

...

what is important for me is that we distinguish what is related to the UI flow from the loading of a specific tests libraries. RIght now I would like to concentrate on UI flow and tools interaction.

Oh, okay - got it. In that case: +1 for autotest-like functionality, where appropriate tests are run when code is saved (I haven't thought through how it could work, but it sounds great; maybe run tests that are senders of the saved method?)

You may have a lot of noise. I guess that Ruby uses files as a unit of development/deployment. The closest Smalltalk/Pharo has is the class and the package. I would suggest that TestCase which would use this feature use some pragma/method to identify/declare which classes/packages this test depends upon. Then the "autotest" framework would register such tests and listen for changes in the given classes/packages, launching required tests whenever a change happen. Additionally, one could declare such a pragma on a single test method, when this test should be run for a specific class. Of course, you also to take care of long running tests, which you probably want to exclude from auto-testing. -- Simon

On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <alexandre@bergel.eu>wrote:

...

You may have a lot of noise.

I guess that Ruby uses files as a unit of development/deployment. The closest Smalltalk/Pharo has is the class and the package.

I would suggest that TestCase which would use this feature use some pragma/method to identify/declare which classes/packages this test depends upon. Then the "autotest" framework would register such tests and listen for changes in the given classes/packages, launching required tests whenever a change happen.

Additionally, one could declare such a pragma on a single test method, when this test should be run for a specific class.

Of course, you also to take care of long running tests, which you probably want to exclude from auto-testing.

I see autotest in Pharo in a slighly different way: When I press save in the Monticello browser, I have a popup menu which asks me whether (i) I want to run all the tests or (ii) only the tests that cover that I changed from the last version.

Does this make sense?

Please no popup :) What I like in ruby autotest is that I can quickly look at test results if I want (or not) without stop writing. Often you want to see your tests failing, as you type / save code. I don't have to stop writing, click a button, wait test results, go again.... testing is done in background and I just see notifications whether it's OK or not. So test log in a Transcript is OK for me. For autotest unit of work is file: it runs the test file which has the same name as the code file, but you can customize this behavior. For autotest-rails: "A simplified version of Autotest heuristics in this mode would be: When changing a test file, only this file is run (e.g. test/unit/foo_test.rb →test/unit/foo_test.rb). When changing a model file, only associated unit test file is run (e.g.app/models/foo.rb → test/unit/foo_test.rb). When changing a controller file, associated functional test file is run (e.g.app/controllers/foo_controller.rb →test/functional/foo_controller_test.rb). When changing a fixture file, associated unit test and functional test are run (e.g.app/fixtures/foos.yml → test/unit/foo_test.rb +test/functional/foo_controller_test.rb). When changing a helper file, associated functional test file is run (e.g.app/helpers/foo_helper.rb →test/functional/foo_controller_test.rb). When changing application_helper.rb file all functional test files are run (e.g.application_helper.rb → test/functional/*_test.rb). When changing a file under the config directory, all tests are run." Laurent

Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project