recognition.feature

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

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.