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