--
-- Rules --
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
You received this message because you are subscribed to the Google Groups Cukes group. To post to this group, send email to cu...@googlegroups.com. To unsubscribe from this group, send email to cukes+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Gherkin 3 sounds great, but the line "Reports would follow the Unit/Fragment structure instead of the Gherkin source structure" worries me a little. Could this be detrimental to Cucumber's current ability to let you know what language in your feature file is causing you problems. Cucumber's current ability to let its output follow the original Gherkin source is rather important for situations where you want to use Cucumber to document what your application is currently doing. If you could only have a more granular output, the difference between the text of the source and output would be significant, particularly for people who make extensive use of tables and example groups.
# Rel. 0.2 MP & MM 27/11/2012 # Project Test # file First.feature # Brief descriptive text # Feature: Device startup To be able to use the system... bla bla bla and then... bla bla I must... bla bla bla @beforeEveryScenario Background: Given the device is installed in the right place And is connected to the power source And is connected to the communication media @subscenario @success Scenario: Device startup procedure completed Given User powered up the device When Device started and completed self test procedure without errors Then Ready.Led = YELLOW.ON And Device.Status = StartUp @subscenario @fail Scenario Outline: Device startup procedure failed Given Device startup procedure completed When Device finished the procedure returning <error> Then Device.Led.color = <color> And Device.Led.status = <light> And Device.Status = <status> And User switches OFF the power source switch And User repeats the device startup procedure or calls the technical service Examples: Errors | error | color | light | status | comment or reference | | NO POWER | - | - | - | | | ROM CRC | RED | FIXED | ROMFLT | | | RAM | RED | BLINK | RAMFLT | | | RF | YELL. | FIXED | RFFLT | | | NONE RFID | ORAN. | FIXED | RFIDFLT | | # # Here I place suggestions, observations and criticisms emerged by discussion with the team # and with the customer and every other note should be useful to modify the scenario # it is a temporary block that will be deleted after the modified implementation will be ready # tested, confirmed and approved (the history is preserved by the source code version control system # @subscenario @success Scenario: User is known Given User inserted the user's card in the slot And the card was previously written with data for a normal user When Device knows the user Then Ready.Led = GREEN.ON And Device.Status = Ready @subscenario @fail Scenario: User isn't known Given User inserted the user's card in the slot And the card was previously written with data for a wrong user When Device doesn't know the user Then Ready.Led = RED.ON # # Here I place suggestions, observations and criticisms emerged by discussion with the team # and with the customer and every other note should be useful to modify the scenario # it is a temporary block that will be deleted after the modified implementation will be ready # tested, confirmed and approved (the history is preserved by the source code version control system # @mainscenario @success Scenario: User logon and device ready to work Given Device startup procedure completed And User is known When Device receives the 1st data string from GPS Then Device updates geographic position And searches for the nearest server And connects to the sensor network @mainscenario @fail Scenario: Device not ready to work Given Background conditions satisfied When Device startup procedure failed Then Device isn't operational @mainscenario @fail Scenario: Device doesn't recognize the user Given Device startup procedure completed When Device doesn't recognize the user Then Device isn't operational # # Here I place suggestions, observations and criticisms emerged by discussion with the team # and with the customer and every other note should be useful to modify the scenario # it is a temporary block that will be deleted after the modified implementation will be ready # tested, confirmed and approved (the history is preserved by the source code version control system # #END OF THE EXAMPLE This example is the result of an initial discussion where was realized only the successful @mainscenario and then it was detailed better with @subscenarios to translate the initial idea to executable test steps that are sufficient to test the real application. I know that there is some skepticism about this way to write BDD style testing requirements but in my personal experience it is very well suited in the embedded field to simply automate acceptance tests (also if it needs some improvements). As you can see it is not so simple to define a main scenario to collect every sub scenario inside. The best strategy I implemented instead to implement the 3 @mainscenario is to use a Scenario Outline as this: @mainscenario Scenario Outline: Device startup Given Device startup procedure completed When Device startup procedure completed returns < startError > And User recognition completed returns < userError > Then Device.Led.color = <color> And Device.Led.status = <light> And Device.Status = <status> Examples: Errors | startError | userError | color | light | status | comment or reference | | NO POWER | - | - | - | - | | | ROM CRC | - | RED | FIXED | ROMFLT | | | RAM | - | RED | BLINK | RAMFLT | | | RF | - | YELL. | FIXED | RFFLT | | | NONE RFID | - | ORAN. | FIXED | RFIDFLT | | ... | NONE ERROR | UNKNOWN | RED | FIXED | RFIDFLT | | | NONE ERROR | KNOWN | GREEN | FIXED | READY | | as you can understand in this case is not possible that the system could begin to test the user if the startup failed but in many other situations I found it is possible so the table grows and is not so simple to maintain it. So I think Gherkin could support a model where a main scenario should be the result of the composition of some sub scenarios and sub scenarios should be seen as steps of it so that I could re assume my idea in this way: MainScenario: Device startup #the same title of the feature Background Step(Device startup procedure, @success, @fail) #title and a scenario list with every element comma separated Step(User logon, @success, @fail) After we could identify the scenarios with a tag next to @scenario and @subscenario or we can identify them by the title assuming the same title and @success or @fail tags to identify the purpose of the scenario. In my opinion this should simplify the translation of the scenarios to executable code and could help to decompose scenarios in a more detailed scenarios that should be useful in some situation to produce an executable scenario more near to the implementation to improve the testability. Another thing that should be very useful is to change the meaning of Background to Before and After, so that should be possible to have a Before that is common to every scenario in a feature (I mean a block that should be true before every scenario) and a Before that should be specific for a particular scenario. The same concept should be used for After.
Oggetto: | Re: [Cucumber] Gherkin 3 - the road to a simpler Cucumber |
---|---|
Data: | Sat, 02 Feb 2013 15:36:32 +0100 |
Mittente: | Massimo Manca <massimo....@gmail.com> |
A: | cu...@googlegroups.com |
OP?
Think of each line in a feature as being a method call. You can always replace any number of lines in a feature with just a single line by
1. Giving a name to the collection of lines you want to call2. Creating a new method (line in a feature) with that name and then calling it
All this stuff about MainScenario etc. can already be done by Gherkin. The only restriction is that if you try and have the collection of lines and the scenarios that use the method that aggregates the collection of lines in the same file then things get messy. But why would you want to that, when you have a file hierarchy available to organise things.
So (in super rough pseudo ruby/gherkin)
# feature 1Scenario:foobarbaz
Feature: Sign inAs a registered userI want to sign inSo I can be recognised by the siteBackground:Given I am registered as 'Fred'Scenario: Sign inWhen I sign inThen I should be signed inScenario: Sign in with bad passwordWhen I sign in with a bad passwordThen I should be signed outScenario: Sign in with bad emailWhen I sign in with a bad emailThen I should be signed out
Here the happy path is 'sign in' and the sad paths are extensions of signing in with bad data
This means is no way you can understand the behaviour of the test code from the gherkin.
The best you can hope to achieve is to clearly describe what the behaviour is and why is it important. Perhaps this is the reason you feel you have to put so much of the 'how' in your features.
Doing Behaviour Driven Development doesn't mean that you have to express every detail of how something behaves in your features.
Quite the opposite. Features were designed to hold the essence of the behaviour, the what and why, not to include the how. You feel that because you are working with embedded systems you have to include much more of the how in your features and that gherkin should change to accomodate this. The way I see things embedded systems are no different from web applications, or web services or api's.
They are all things which have behaviour which can be described at various levels of abstraction. In each case gherkin gives you the power to choose what level of abstraction you wish to work at. If you choose wisely you can make development much simpler and allow your features to communicate just enough information to explain what is being done and why, without overwhelming the reader with too much information.
However if you don't understand how to work with multiple levels of abstraction, or you don't have the language skills to express yourself fluently at different levels of abstraction, or if you think gherkin should explain how the test works then you will find gherkin limiting, and will want to add extra constructs to it. You are not the first person to have asked for these additional constructs in gherkin, and I am sure you will not be the last. Your problems are not unique, your requests are not unique, but your understanding (like every human beings) is unique. Perhaps you can solve your problems best by developing/changing that.
You said:
"Just to be clear an embedded system must detect different error conditions then a web application or a PC application and we need to write specific requirements to test all error conditions".
This seems to be a pretty clear description of exhaustive testing. Cucumber and Gherkin are not suitable tools for this. If you want to do exhaustive testing you should use unit test tools to "test all error conditions". You can't do everything with one tool, and you can't test everything with one test.
Gherkin already addresses the needs of embedded systems. You just have to choose the correct level of abstraction for your particular context. And yes this will mean making compromises on what your features contain, but that is the nature of writing features. Your current features are telling you that you haven't yet found a suitable level of abstraction, but your not listening to them. You don't need to change Gherkin, you just need to change your features.
Hi Aslak,I know this is a really old post. I am curious what the roadmap for Gherkin 3 is. Is it even still a thing? I've seen the gherkin3 repo but it doesn't seem very active. Could you shed some light on the status and future of Gherkin? Thank you!
--
Posting rules: http://cukes.info/posting-rules.html
---
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cukes+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Aslak,
Thanks for your quick reply. That's really interesting. So would the first step be to port berp to Ruby/JS/Java?
I'm interested in helping out and I'm also interested in a Swift/ObjC port. My time is very limited, though (as everyone else's is too :)).
On 27 Feb 2015, at 23:32, aslak hellesoy <aslak.h...@gmail.com> wrote:
On Fri, Feb 27, 2015 at 8:45 PM, Johannes Fahrenkrug <jfahr...@gmail.com> wrote:I'm interested in helping out and I'm also interested in a Swift/ObjC port. My time is very limited, though (as everyone else's is too :)).That would be awesome.
No. Berp is a parser generator. It happens to be implemented in C#, but that is irrelevant since it can output parsers in any language. Berp is used to generate parsers for all Gherkin implementations. It takes a grammar file (gherkin.berp) and a template (gherkin-X.razor) and outputs a parser in language X. The lexer and Ast code is hand-written.
I'm interested in helping out and I'm also interested in a Swift/ObjC port. My time is very limited, though (as everyone else's is too :)).That would be awesome. I guess we need to write up some docs about how to contribute!