Thanks Karlsson,
I do agree that using tables to pass scenario data is a nice
feature and I do apply it when appropriate.
However I tempt to disagree with you that this could be an
approach for everything.
Two type of reasons for this:
1.
Business related:
What business people what to see is a work flow case in
their language. Putting all the scenario data in one place is would be like
pointing my scenario direct to a file storing that data (say a SWIFT file or an
XML, or some other format). You can just say “Given my payments system receives
a FX message as described by the file xyz.xml” but then you miss the whole
point of having BDD as you can easily create a jUnit test where you pass the
same file to your system and see what happens after processing.
By doing this you divorce from business as they will
never accept a story run report in which all they have is a file name.
So you need to leave your data in the story and when
that data is a lot then the story would be hard to comprehend regardless of
what format you use for that table; eg. One row with lots of columns, multiple
row
table, key value similar to properties table, etc
More than this some data may be optional or not which
means that you can’t use the same structure for multiple scenario and that
would make it difficult to comprehend how a scenario differ from each other.
And in the end what about a scenario with no data but
many, many steps. By the end of the day we call it a story don’t we IMAO? You
would still need to make that as fluent as possible won’t u?
2. Technical related:
One row table with tens of columns may result in a
method with tens parameters. No need to
say what this would be bad.
Multiple rows table with less columns would more
likely result in complicated steps implementations as you will have to parse
the data and consider optional values, etc. You most likely will give this up
and rather go with a key value representation which will make your story look
like a data file rather than a BDD scenario.
You will have lots of private methods in your steps
classes performing different actions depending on that data that should
otherwise be exposed to the business. That will result in lots of if statements
inside your code (an optional value is there or is not, setting a given locale
when the currency is the Japanese Currency, etc). That would be a maintenance
nightmare.
In conclusion, in my opinion expressing our business case in
a natural language that make it accessible to the business with absolutely no
efforts
is the main reason BBD was invented. It gives them (the business people) a way
to easy get the confidence that we are delivering to them.
This said I do use table data a lot whenever I find it appropriate.
Cheers,Julian
--- On Tue, 12/2/13, Karlsson Christian <christian.karls...@cag.se> wrote:
From: Karlsson Christian <christian.karls...@cag.se>
Subject: RE: [jbehave-user] User defined keyword
To: "user@jbehave.codehaus.org" <user@jbehave.codehaus.org>
Received: Tuesday, 12 February, 2013, 1:14 AM
#yiv61419117 P {
MARGIN-BOTTOM:0px;MARGIN-TOP:0px;}
Hi
In such case I would use the table format to enter all the characteristics of
the event.
Given our Payments system supports SWIFT messages
When a FX transaction message arrives on the form
|from|to |exchange rate|transaction date|amount|account |...|
|USD |GBP|0.71002 |tomorrow |200.00|1234567890|...|
Which would give a more readeble format IMHO.
Regards
Christian Karlsson
CAG Contactor AB
Adress: Jan Stenbecks Torg 17, SE-164 40 Kista
Mobil: +46 (0)706694527
Mail: christian.karlsson <at>
cag.se
www.cag.se
From: Iulian Greculescu [julian_grecule...@yahoo.com.au]
Sent: Monday, February 11, 2013 12:05 PM
To: user@jbehave.codehaus.org
Subject: Re: [jbehave-user] User defined keyword
@Handa,
If I understand well the sub scenario need this can be achieved by including
that sub scenario part of a standalone story and then making your each scenario
that has your sub scenario a prerequest running with a GivenStories pointing to
that common story.
We applied this lots of time when exercising a banking system.
Say you have the user login story your common thing and then you have: a BPay
payment, a Bank Transfer, an International Payment, etc. All these scenarios
would gave a GivenStories UserLoginStory, etc
@Mauro
The user defined keyword attracted my attention quite a lot. I accept that you
can describe a business case just using Given/When/Then/And suite. However when
the scenario you need to write is a long one (say 30 or more steps) I have to
accept that the story
starts sounding a bit to fade (say made up). It works but....:)
When this post came I was just about to come up with an idea/proposal to bring
some spice in our stories and make them sounds more natural. What about
including the flexibility of defining "And" synonyms with exactly the same
functionality as the actual "And"?
So you can say something like this:
Given our Payments system supports SWIFT messages
When a FX transaction message arrives
And the "from" currency is USD
And the "to" currency is GBP
And the exchange rate is 0.71002
And the transaction date is the next business day
And the transaction amount is $200.00
And the payer account no is 1234567890
....
And 30 others "when" steps describing the Foreigner Exchange message
Then.....
Someone would say (me included) that if I can say "With' and "Having" are
synonyms of "And" and rewrite the story like below then it would sound more
natural.
Given our Payments system supports SWIFT messages
When a FX transaction message arrives
Having the "from" currency as USD
And the "to" currency as GBP
With an exchange rate is 0.71002
......
What do u think? I was thinking to research a bit how difficult that would be.
Regards,
Julian
--- On Mon, 11/2/13, Mauro Talevi <mauro.tal...@aquilonia.org> wrote:
From: Mauro Talevi <mauro.tal...@aquilonia.org>
Subject: Re: [jbehave-user] User defined keyword
To: user@jbehave.codehaus.org
Received: Monday, 11 February, 2013, 2:36 AM
You can request new features on JIRA:
http://jbehave.org/issue-tracking.html
That said, your features require substantial changes and are more likely to be
considered for the 4.x releases.
On 10/02/2013 15:13, Handa, Ramneek wrote:
#yiv61419117 UNKNOWN {
FONT-FAMILY:"Cambria Math";}
#yiv61419117 UNKNOWN {
FONT-FAMILY:Calibri;}
#yiv61419117 UNKNOWN {
FONT-FAMILY:Tahoma;}
#yiv61419117 P.yiv61419117MsoNormal {
FONT-SIZE:11pt;FONT-FAMILY:"Calibri", "sans-serif";COLOR:black;MARGIN:0in 0in
0pt;}
#yiv61419117 LI.yiv61419117MsoNormal {
FONT-SIZE:11pt;FONT-FAMILY:"Calibri", "sans-serif";COLOR:black;MARGIN:0in 0in
0pt;}
#yiv61419117 DIV.yiv61419117MsoNormal {
FONT-SIZE:11pt;FONT-FAMILY:"Calibri", "sans-serif";COLOR:black;MARGIN:0in 0in
0pt;}
#yiv61419117 A:link {
COLOR:blue;TEXT-DECORATION:underline;}
#yiv61419117 SPAN.yiv61419117MsoHyperlink {
COLOR:blue;TEXT-DECORATION:underline;}
#yiv61419117 A:visited {
COLOR:purple;TEXT-DECORATION:underline;}
#yiv61419117 SPAN.yiv61419117MsoHyperlinkFollowed {
COLOR:purple;TEXT-DECORATION:underline;}
#yiv61419117 SPAN.yiv61419117EmailStyle17 {
FONT-FAMILY:"Calibri", "sans-serif";COLOR:windowtext;}
#yiv61419117 SPAN.yiv61419117EmailStyle19 {
FONT-FAMILY:"Calibri", "sans-serif";COLOR:#1f497d;}
#yiv61419117 SPAN.yiv61419117EmailStyle20 {
FONT-FAMILY:"Calibri", "sans-serif";COLOR:#1f497d;}
#yiv61419117 .yiv61419117MsoChpDefault {
FONT-SIZE:10pt;}
#yiv61419117 UNKNOWN {
MARGIN:1in;}
I would love to have ability to write a sub scenario which is a part of many
scenarios so as to avoid repetition.
@Before/@AfterScenario/... – as a coder of my tool I wouldn’t know what the
story writer would like to do at teardown and setup.
Unfortunately these two are very basic needs for me to use JBehave. Is it not
done because its complex given how JBehave is implemented or has it never been
the priority?
I can write my requirement and file an issue if you think this can be supported
soon?
Regards
From: Mauro Talevi [mailto:mauro.tal...@aquilonia.org]
Sent: Sunday, February 10, 2013 10:39 PM
To:
user@jbehave.codehaus.org
Subject: Re: [jbehave-user] User defined keyword
You can define "composite steps" from other defined steps:
http://jbehave.org/reference/stable/composite-steps.html
User-defined keywords are not supported, the only keywords allowed in the
scenario steps are "Given/When/Then/And" but the rest of the step language is
entire up to you to define. You can also change the existing ones, ie use
different values for them, via
i18n support. The idea being that Given/When/Then represent generic step
types (precondition/event/result) and you should be able to fit comfortably
into these types by appropriate use of the step language that follows.
There is no setup/teardown in the story syntax, i.e. something executed before
and after *each* scenario or story. There is however :
- GivenStories ... i.e. one or more stories executed on demand (i.e. on
explicit invocation) before scenarios or stories.
- @Before/@AfterScenario/Story/Stories ... i.e. annotated steps in code that
are executed before each scenario/story/group of stories
On 10/02/2013 13:59, Handa, Ramneek wrote:
Hi Guys,
Is it possible for the story writer to create new higher level steps (which
consists of multiple steps)? I am moving from robot framework and it has this
feature of user defined keywords that i couldn’t
find in jbehave website. Could someone please point me in the right direction?
Also, i would like to know if there is a way for story writer to write
setup/teardown in gherkin?
Regards,
Ramneek
This email and any attachments are confidential and may also be privileged. If
you are not the intended recipient, please delete all copies and notify the
sender immediately. You may wish to refer to the incorporation details of
Standard Chartered PLC, Standard
Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html.
This email and any attachments are confidential and may also be privileged. If
you are not the intended recipient, please delete all copies and notify the
sender immediately. You may wish to refer to the incorporation details of
Standard Chartered PLC, Standard
Chartered Bank and their subsidiaries at
http://www.standardchartered.com/en/incorporation-details.html.
