About TDD and Pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
56 messages Options
123
Reply | Threaded
Open this post in threaded view
|

About TDD and Pharo

Stéphane Ducasse
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Guillermo Polito
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 :(

On Wed, Jun 2, 2010 at 4:30 PM, Stéphane Ducasse <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Alexandre Bergel-4
In reply to this post by Stéphane Ducasse
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Germán Leiva
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 <[hidden email]>
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Germán Leiva
[hidden email]

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Sean P. DeNigris
Administrator
In reply to this post by Stéphane Ducasse
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Denis Kudriashov
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 <[hidden email]>


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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Stéphane Ducasse
In reply to this post by Germán Leiva

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?

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

if you have code I would be really interested.
I know hernan did some extensions in the past

>
> Cheers
>
> 2010/6/2 Alexandre Bergel <[hidden email]>
> 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
> > [hidden email]
> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>
> --
> Germán Leiva
> [hidden email]
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Stéphane Ducasse
In reply to this post by Sean P. DeNigris

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Stéphane Ducasse
In reply to this post by Denis Kudriashov
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 <[hidden email]>
>
>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Stéphane Ducasse
In reply to this post by Sean P. DeNigris
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

laurent laffont
In reply to this post by Stéphane Ducasse
In ruby world the tools I like most for TDD are:

- autotest: when you save a file, autotest detects it are run automatically associated unit tests. http://ph7spot.com/musings/getting-started-with-autotest. For PHPUnit there's a light autotest-like http://gist.github.com/287950. I really like it as you have a smooth workflow, don't think about which test to run, quick feedback. Brings lot of confidence.

- shoulda: macros, contexts and understandable tests. http://github.com/thoughtbot/shoulda


Laurent Laffont

http://pharocasts.blogspot.com/
http://magaloma.blogspot.com/


On Wed, Jun 2, 2010 at 9:30 PM, Stéphane Ducasse <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Denis Kudriashov
In reply to this post by Stéphane Ducasse
Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <[hidden email]>
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 <[hidden email]>
>
>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Mariano Martinez Peck
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 <[hidden email]>
Hello, No I dont. Who is it?

2010/6/3 Stéphane Ducasse <[hidden email]>

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Mariano Martinez Peck
In reply to this post by Germán Leiva


2010/6/2 Germán Leiva <[hidden email]>
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 

Germán, these are cool ideas. Some of them I think they are in the Hernán package. It would be greate to check which features does it have, and create (and code!) a list of new features, like this ones.


 
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


Yes, open a ticket and put the list. I would like you can code on this also but I guess you are busy with GSoC ;)
 
Cheers

2010/6/2 Alexandre Bergel <[hidden email]>

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


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project



--
Germán Leiva
[hidden email]

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Sean P. DeNigris
Administrator
In reply to this post by Stéphane Ducasse
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
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Sean P. DeNigris
Administrator
In reply to this post by Stéphane Ducasse
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?)

Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Simon Denier-3

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




_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Alexandre Bergel
> 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?

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






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

laurent laffont


On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <[hidden email]> 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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: About TDD and Pharo

Alexandre Bergel
The idea is excellent.

Cheers,
Alexandre


On 3 Jun 2010, at 10:22, laurent laffont wrote:

>
>
> On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <[hidden email]> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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






_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
123