Details
New Feature
Resolved
Major
Description
To get more natural German story texts, it would be very helpful if the Steps.listCandidates() method could be amended.
This would allow for automatically generating slight variations of the texts without having to specify them all as aliases. Currently I am doing this:
@Then("soll foo bar with $xyz")
@Aliases(values =
)
The word "soll" is made optional this way. The reasoning behind this is that when using "And" it is more natural to write
Then soll something else
And foo bar with $xyz
instead of
Then soll something else
And soll foo bar with $xyz
It would be very nice to not have define aliases for all these variants, because it makes the code harder to maintain. Instead, I though I'd add this dynamically, the same way annotated Aliases are, but it seems this functionality would require providing a new subclass of org.jbehave.core.steps.Steps which I cannot see how to do.
I suggest a change like this:
1) In org.jbehave.core.steps.Steps add another call in listCandidates() after each of the addCandidatesFromAliases(...) like addCustomDerivedCandidates(...) with the same signature and a protected empty default implementation.
2) Allow configuration to specify a custom subclass of org.jbehave.core.steps.Steps. In there custom additions to the candidates list could be made, like the one I described.
Activity
Here a few examples where I would not like to create an alias for given and then cases, because they would be virtually identical, but for the "variant" word.
A little German lesson upfront 
- Gegeben = Given
- Dann = then
- sei = be
- soll = should
The "sei" (be) is associated with the first "Gegeben" in a German sentence, further conditions added with "and" do not repeat it. Doing so would be very awkward language.
The same goes for "soll" (should). The first part of a "Then" very often gets it, the following ones do not.
The difference to, say, English is a) the repetition and b) the order of the words. While in English you'd write
... then A should be 1 and B should be 2 ...
in German it would be
... dann sollte A 1 sein und B 2 sein ...
So, I agree to your idea that a new attribute of the existing Alias/es would be enough, because that's what it really is. What I am trying to avoid is having to multiply aliases to build all permutations with these variant words in front of them (there are a few more than "sei" and "soll", e. g. "sollte" as an equivalent to "soll" in most cases).
Having a way to add these concisely would increase legibility of the code and also help avoid copy/paste errors.
A few examples:
--------------------
Good:
Gegeben sei eine Usersession ["sei" for the first case]
Und ein Artikel im Warenkorb [no repeated "sei"]
Also good, equivalent:
Gegeben sei ein Artikel im Warenkorb ["sei" for the first case]
Und eine Usersession [no repeated "sei"]
Not Good:
Gegeben sei eine Usersession
Und sei ein Artikel im Warenkorb [repeated "sei" very awkward]
--------------------
Could be written as
@Given("eine Usersession")
@Aliases(values=
,variants=
{"sei"})@Given("ein Artikel im Warenkorb")
@Alias(variants={"sei"}
)
--------------------
Good:
Dann soll eine Meldung angezeigt werden ["soll" for first case]
Und ein Logeintrag geschrieben werden [not repeated]
Not Good:
Dann soll und ein Logeintrag geschrieben werden
Und soll eine Meldung angezeigt werden [repetition awkward]
--------------------
Could be written as
@Then("eine Meldung angezeigt werden")
@Aliases(variants=
@Then("eine Meldung angezeigt werden")
@Aliases(variants={"soll","sollte"}
)
Without the variants, I would either need to write down a lot of aliases explicitly, or the people writing the tests would not be at their leisure to modify the order of the conditions they use without sacrificing natural language rules.
I hope I get the point across. It is a little difficult to describe the peculiarities of one language with the words of the other
Alright, I have come up with something that would work for me. Feedback appreciated
It is based on the premise that the usual case would be to have some parts of a step be optional or picked from a list of variants like so.
Example 1: two variants
@When("$A plus $B") @Alias("$A + $B")
could become:
@When("@$A {plus|+}")
Example 2: optional phrases with alternatives
@Then("the result be $x") @Alias(values={"the result must be $x", "the result should be $x", "the result has to be $x"})
could be written as
@Then("the result {must |should |has to |}be")
Here the trailing | introduces an "empty" variant, essentially making the pattern optional.
Example 3: multiple patterns in one step
It is possible to have more than one pattern group in a step description.
@Then("A {must |has to |is to |} be $x unless {it's|it is} {part of|contained in} {list |}$y")
In this example writing this with aliases would result in 31 aliased variants (4*2*2*2 permutations).
I will attach a small ZIP file containing a modified Steps class and the permutation builder I have hacked together. As said before, any feedback is welcome.
Hi Daniel, not very clear how your "dynamical" approach would work and how generic this solution would be. Can you provide an example of your proposed addCustomDerivedCandidates().
In general, I think subclassing steps is not a good solution as it mixes declaration and implementation.
If there is a need, we can enhance the declarative functionality, either via modifying the @Aliases annotation or providing a new one.