This is the task I would really like to participate in. Although, just as you, I have no time at all, I still *will* find at least few hours a week :)
-- Best regards, Dennis Schetinin 2013/12/3 Denis Kudriashov <[email protected]> > 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 >> >> >
