-
-
Save icambridge/7694d6d7b0a987f6c33b to your computer and use it in GitHub Desktop.
Scenario: Recognise outside of heirachry with line manager recognition approval and reward control table director approval | |
Given I am logged in to the system | |
And recognition approval is set to manual by line manager | |
And reward approval is set to manual with a budget control table of: | |
| Director | 100 | | |
| Plus one | 50 | | |
| Line Manager | 1 | | |
When I recognise someone outside of my heirarchy for "150" | |
Then the recognition status should be pending | |
And the reward status should control tabled | |
And the line manager should be notified of pending recognition | |
And the director should be notified of pending reward | |
But no money should be transferred |
@mackstar the missing details are:
- A thing called Slot representing period of time
- A thing called Track representing a numbered conference track
- A thing called Conference that must be named and should have a specific amount of tracks
- A thing called Talk that always have a name and could be scheduled for a specific track and slot at the conference
- A thing called Personal Schedule
- The act of selecting talk from conference into a Personal Schedule is called "choosing"
All these details are missing from your examples, yet are very important if you have a complex domain at hand that you want to explore without cost of translation. The reason why you missed all them is that you're probably working in the relatively simple domain, that doesn't require you to focus on that part of the conversation. You used to work with the domain that doesn't need these details, thus you're very comfortable without them. Yet, most of the projects BDD aimed for do have complex domains and do require exploring these language artefacts :)
@everzet Good points, but adding this detail is just a case of jigging things a little. If anything I should have been been able to have more easily recognised that from your scenarios ;-).
Conference Management Tool
This is a tooling platform for atendees and conference staff to be able to manage conference details over the web.
In this example the conference is named 'Symfony Live 2014'.
- IT has a specified conference name
Personal Scheduler
This is so atendees can worry less about boring stuff and more about socialising.
Choosing a Talk
Tracks
- IT has specified numbered tracks
Singular
This talk is named 'Advanced Symfony' and is at the single time slot of "10:30-11:30".
- IT enters 1 talk into my personal schedule when I choose it
- IT contains the talk name and the talk time
Multiple Clash
The 'Agile for Dummies' talk is at the same time as 'Advanced Symfony' at '10:30-11:30'
- IT only adds 1 talk to my personal schedule
- IT notifies me that another talk has been taken by that time slot
@mackstar and this is exactly the point where Gherkin starts being both shorter and easier to follow :)
Job done - all though I am sure you might have more criticism but I think this method does have merits.
- Eye catching authoritative domain based contexts
- A hierarchy can be expressed as needed
- Acceptance criteria has been separated from descriptions
- Points needing testing are clearer
- There is less duplication meaning it is easier to read
- It looks great as it is converted to mark-up
... that's because Gherkin is optimised for being expressive representation of conversation, where's it should ...
is optimised for being short. As I said - we work on different levels of details :)
It is obvious to me that all the pain you guys had at BBC in regards to Cucumber was caused by the fact that you treated Cucumber as a generalised testing tool for all application levels. But you're kinda making the same mistake now with ShouldIT?, by trying to replace Gherkin as generalised testing tool with ShouldIT? as another generalised testing tool. Treating any of these tools as a general solution for testing (or development) as a whole is wrong and will eventually cause you only pain. Use the right tool for the right problem and at the level of details required to solve it properly.
Shorter? Gherkin example you gave 211 words ShouldIT? example 152. Repetition close to 0.
I will stop there are we are going round in circles now and I feel your last comment was slightly off topic.
I preface the following with the fact I've not used ShouldIT, and all of this is opinion.
I think as has already been said, the two systems are working at different levels, so whereas Behat is more a powerful, configurable tool which is very expressive and (when used properly) will let you control the fine-grain details of your testing, ShouldIT appears to be more of a simpler tool which (may have) less configurability and is easier for people to just pick up and use.
From a usage point of view, ShouldIT would be the tool I give to my junior developer who has no experience of testing. It should be easier to pick up and use. When my junior developer stop being so junior and starts understanding the problem domain and how to write more powerful code, then introduce them to Behat as the power tool of BDD.
@stevangoode Thanks for your comments, it is nice to hear a voice that understands the position from both sides of the fence ;-).
@mackstar I advise you to re-read the thread and rethink your current warmonger position. There's no "fence", "war" or "protectionism" anywhere in this discussion except from you. You're artificially creating the battle between the tools by trying to prove that one tool is better than another as a general solution for any testing problem out there. They both suck at that. They are solutions for different problems living at different levels of complexity.
@everzet I did not mean it to sound that way - I meant someone who can see both perspectives. They are 2 perspectives.
But you can't tell me that ShouldIT? Sucks at something because you haven't tried it (at all). This is an opinion. You set the examples. You can see my responses have tried to take into account the subject being brought up at hand. I am interested in exploring these arguments. You are right this is not a 'war' and maybe no 'fence' and I am not trying to make it that. But if someone says ShouldIT? cant do something I at least want to explore that conversation and ask others opinions. That is how this GIST started by someone suggesting that ShouldIT? cannot deal with complex examples. I want to find out even myself if it can or it can't.
Guess I'm a little late but I wanted to add my two cents. So I wrote about it: http://blog.rtens.org/tool-tyranny.html
tl;dr - I don't think this discussion is so much about tools as it is about description style and structure. The tools should not dictate a style though. So my approach is to use a tool only for browsing and presentation, not for the specification itself.
@rtens using a parsing adapter could mean more flexibility should the user want to change the structure. But doing so would make it increasingly difficult to match the features to the tests.
So far this style has worked great for us which is why that is the default. I will be focussing on 'Domain Driven Design' in future ramblings, the reason behind styling it this way may then be a little more clear.
Thanks for the reply. As you say its all good discussion. My aim is not to hinder the development of your tool and I really admire the effort that you have put into it 👍 However I started my exploration into BDD using a tool and assuming I was doing good BDD but in reality I broke every rule there should be. My aim now is to promote real conversation with humans and have the tools present to compliment the process.
Tomorrow I will write out a example of a checkout process that we can explore both methods to see if we can understand both methods a little more. To me the checkout is a great example as there is a lot of business value that can be captured and is easily misplaced such as promotional price rules, delivery costs, shipping zones, restricted products etc that make for interesting feature files in Gherkin and will lead to ( for me anyway ) a better insight into how you see Should It? being used.
Thanks again and thank you for your time.