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