Re: [Pharo-project] Phexample should methods
On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote:
That gives rise to example-driven testing ala:
Foo >> #barShouldBeSomething
So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name.
Any opinions on that?
Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods (imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class. I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ... Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome!
PS: It is also inconsistent with Phexample's own #isTest: implementation, which uses #beginsWith:
Oops, that's a bug, #theMoreGeneralCaseShouldApply :) Even though personally I prefer to not use should inside the name in order to limit the pollution for the selection name space with regard to Smalltalk's simple autocomplete ... --AA
On 19 Feb 2013, at 7:59, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote:
That gives rise to example-driven testing ala:
Foo >> #barShouldBeSomething
So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name.
Any opinions on that?
Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods
I'm not sure I understand you correctly: in Ruby you also only have classes and methods. Those apparently independent methods (top level defs, describe blocks, ...) are all methods on Object. It's just that Ruby lets you (in the case of def) leave out the "on Object" part or (in the case of describe has special eval forms (and implicit receivers) which make Ruby look like it supports anything other than methods. frank
(imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class.
I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ...
Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR
Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome!
PS: It is also inconsistent with Phexample's own #isTest: implementation, which uses #beginsWith:
Oops, that's a bug, #theMoreGeneralCaseShouldApply :)
Even though personally I prefer to not use should inside the name in order to limit the pollution for the selection name space with regard to Smalltalk's simple autocomplete ...
--AA
On 19 February 2013 07:59, Adrian Kuhn <akuhn@iam.unibe.ch> wrote:
On Feb 10, 2013, at 12:37 PM, Stefan Marr wrote:
That gives rise to example-driven testing ala:
Foo >> #barShouldBeSomething
So far, I tried to avoid that, and make examples that are really focused on one specific subject, which is represented by the class name.
Any opinions on that?
Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with. Other than Ruby we cannot break free from classes and methods (imposed by the Smalltalk IDE rather than the language) so its what we must work with. Personally I like to have a 1:1 mapping between classes and "test classes" as in Stack and StackExamples and then use "test method" names to describe the examples. And then other "test classes" with more complex use cases that cover features involving more than one class.
I am not sure if we ever implemented the following idea, but I seem to recall that I used to name some of my "methods" inside the "example classes" with names such as #givenAnEmptyStack or #givenAStackWithTwoElements and then sending these to create the fixture in the "test methods" #shouldAddElement or #shouldFailWhenPoppingFromEmptyStack etc ...
Essentially, everything you ever type and evaluate in a workspace should be turned into an example, see http://qr.ae/10yZR
Think of it, having a "save as example" menu item available on *every* text selection in the system would be so awesome!
That would greatly lessen the difference between exploratory programming and "classic" TDD, which I think is a great idea. You play around with some code in a Workspace, get something working, and then want to formalise that/record it as a test... and have to open up a Browser and move bits here and there, and it's a bit of a pain. Having this kind of thing - whether a menu item or button or whatever - would remove that source of friction. frank
Great post... a lot to think about :) Adrian Kuhn wrote
Classes and methods are not the best model to structure tests. Alas in Smalltalk it's all we can work with.... we cannot break free from classes and methods (imposed by the Smalltalk IDE rather than the language) so its what we must work with.
I consider classes and methods to be the assembler of specifications (I prefer to "testing"). Because we have our amazing IDE, with Smalltalk turtles all the way down, all there is to do is create a GUI that works the way our minds do. Just like Spec will eventually have a painter covering the raw spec methods, so too can we have a Specification Painter. I started work on this several times, but there was so much cleaning to do in Pharo... But with all the progress made for 2.0, I feel that we are getting closer and closer and have been wanting to resume my work on that this week. It seems that a Morphic overhaul is the only thing left to make that easier, and at least a new text model (one of the more infuriating parts of Morphic) is already underway. Cheers, Sean -- View this message in context: http://forum.world.st/Re-Phexample-should-methods-tp4670589p4670629.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
participants (3)
-
Adrian Kuhn -
Frank Shearar -
Sean P. DeNigris