Markus, I agree that it's helpful for the team to build a shared conceptual model of the system, as you describe below. But it doesn't help with the problem we're discussing, which lies elsewhere.
The problem concerns the language used to express the story -- not with the conceptual model, but with the concrete details of story construction. Cucumber et al require you to express the story in a programming language. An English*-like language, to be sure. But nevertheless, your given/when/thens must assemble into a program with precise (but hidden!) fixture semantics. The difficulty is that some story authors can't, won't, and shouldn't do programming.
Concordion helps by allowing the story text to be in plain English* with no rules. Writing stories is not an act of programming. Programming is relegated strictly to the fixture-izers, who can change the semantics of the fixture DSL without changing the story words.
[* Substitute your favorite natural language]
--- In agile-testing@yahoogroups.com, Markus Gaertner <mgaertne@...> wrote:
>
> One thing that
> could help is a system metaphor is it is described in the first
> edition of the XP book. Eventually the language in your examples will
> help you come up with a system metaphor, and thereby lead to a
> ubiquitous language.
0 comments:
Post a Comment