Problem with TestCase approach is mixing two separate concerns. First is how we want to define system specifications. Another is how we can persist such specifications. When we stay at test case level we lost freedom for specification definition. We restricted with smalltalk language artifacts. For example, how we can group our tests? With classic test case approach we have four levels: packages, classes, protocols and methods. Now remember how many times you put long names for test like #shouldDoingSomethingWhenSomeSitiationHappensDuringAnotherSituationHappenButWhenSituation3NotHappen. And most times you have tests for each separate situation with same long test names. In smalltalk only way to refactor test names duplication is extraction same "when condition" to separate test case classes. But it means that you build classes with very long names and most times your test names stay big (but with reduced length). And do you know way how to group such classes? Only way is put such classes to own class category. Nobody doing this.
Now imagine we don't care how to persist tests (specifications). We can model specifications with explicit objects which present #when, #should and other test artifacts, which can group specifications with arbitrary way. With true objects we don't name our specifications with method name convention. We can name tests with natural language, we can put names for "when" and "should" expressions with natural language. With objects we can build "smalltalk vision" of BDD framework. Really with smalltalk live system testing environment can be very different from other languages. BDD frameworks of other languages just changed names of "TDD dictionary". They all stay restricted with language syntax. So it is my vision. I really want to build such system but I have no time for this yet. Maybe Sean doing something similar? 2013/12/3 Esteban A. Maringolo <[email protected]> > 2013/12/3 Dennis Schetinin <[email protected]> > > > > I see the only correct way to build a good testing environment: tests > should be basically objects, not methods. > > They are objects. Instances of TestCase. > > But for simplicity they're implemented in a single "factory" class, > the TestCase subclass... > > > > Esteban A. Maringolo > >
