[Pharo-dev] Unifying Testing Ideas
chaetal at gmail.com
Tue Dec 3 23:18:40 EST 2013
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 :)
2013/12/3 Denis Kudriashov <dionisiydk at gmail.com>
> 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
> 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 <emaringolo at gmail.com>
>> 2013/12/3 Dennis Schetinin <chaetal at gmail.com>
>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pharo-dev