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

Manual Line Manager Approval

Pending

Outside Heirarchy Request

This is when reward approval for example with a budget control table of:

Position	Budget
Director	100
Plus one	50
Line Manager	1

someone is recognised outside the hierarchy at "150"

• IT sets the recognition status to pending
• IT control tables the reward status
• IT notifies the line manager the pending recognition
• IT notifies the director of pending reward
• IT transfers no money

Although I would need a little more background into the specifics of your system, your question was excellent and showed how well Gherkin does deal with these situations.

Nicely this was on gist so I could show you directly how this would look in 'ShouldIT?'

The main difference is that your loading of data through tables would be summed up in one heading in 'ShoultIT?' this would allow these values to be set in your test under that particular context. That is why contexts are such a key part to the tool.

This then prompts you for test code such as follows:

class ManualLineManagerApprovalPendingOutsideHeirarchyRequestTest extends PHPUnit_Framework_TestCase
{
    public function testSetsTheRecognitionStatusToPending()
    {
        ...
    }

    public function testControlTablesTheRewardStatus()
    {
        ...
    }

    public function testNotifiesTheLineManagerThePendingRecognition()
    {
        ...
    }

    public function testNotifiesTheDirectorOfPendingReward()
    {
        ...
    }

    public function testTransfersNoMoney()
    {
        ...
    }
}

Or in a spec'ing based testing library this would be something like:

describe "Manual Line Manager Approval" do 
    describe "Pending"
        describe "Outside Heirarchy Request" do

            it "sets the recognition status to pending" do
                ...
            end

            it "control tables the reward status" do
                ...
            end

            it "notifies the line manager the pending recognition" do
                ...
            end
        end
    end
end

The other benefit of the ShouldIT? example is that these tests can be ran stand-alone without use of special parsers and libraries like its Gherkin based cousins rely on.

I think that's probably not the best example. It has too many things going on without much of the details. How about this one:

Feature: Attendee selects talks
  In order to spend time socialising at conferences instead of looking at the schedule
  As a conference attendee
  I want to plan my personal schedule beforehand

  Scenario: Successfully selecting 1 talk from the 1 track conference for a single slot
    Given a conference named "SymfonyLive 2014" with 1 track
    And the "Advanced Symfony" talk is scheduled for "10:30-11:30" slot on the conference track 1
    When I choose the "Advanced Symfony" talk for my personal schedule of this conference
    Then my personal schedule for this conference should have 1 talk
    And the chosen talk for "10:30-11:30" slot should be the "Advanced Symfony"

  Scenario: Failing to select 2 talks into the same slot
    Given a conference named "SymfonyLive 2014" with 2 tracks
    And the "Agile for Dummies" talk is scheduled for "09:00-09:45" slot on the conference track 1
    And the "Advanced Symfony" talk is scheduled for "09:00-09:45" slot on the conference track 2
    When I choose the "Agile for Dummies" talk for my personal schedule of this conference
    And I try to choose the "Advanced Symfony" talk for my personal schedule of this conference
    Then my personal schedule for this conference should have 1 talk
    And I should be notified that slot "09:00-09:45" is already taken by another talk

Attendee Selection

This is so they can worry less about boring stuff and more about socialising.

Single Track Conference

Session

This session is at 'Symfony Live 2014' and the 'Advanced Symfony' talk is at "10:30-11:30".

• IT enters 1 talk into my personal selection
• IT contains the session name and the time

Twin Track Conference

Session 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 selection
• IT notifies me that another talk has been taken by that time slot

By defining the context in headings the Domain Driven Design is also more focused. I feel this is easier to understand 'for me'. Again - opinion but the more I think about it, the more it seems to work.

Good one. As I thought, ShouldIt? in this example hides all the information. The thing is, every single word from these scenarios above is important. It gives developer a context and a reference for a language we used to talk about the domain (Ubiquitous Language). And your example just outlines the extraction of both of them.

Simply put - your variant is much shorter, but that's only because it doesn't have as much information in it. Even though for a simple functionality that additional information is redundant, for most complex behaviours this information provides irreplaceable business insight for the development team. As I said - ShouldIt? operates on a different level of detalization, which is fine as long as that's the right level of detalization your problem requires in order to be solved effectively, which it seems to be the case for your project ;)

Just adding my 2 cents.

I totally get that for you the level of detail is ok. However what puts me off your examples is that I don't see the conversation. "IT only adds 1 talk..." leaves me asking what "IT" is. Whereas with the Gherkin I have more understanding over the scenario. It feels more like a conversation that I could have with the BA / Client and offer alternatives in conversation.

I would be interested to see how the tool works with a checkout example for e-commerce as I have wrote and read many good and very poor examples. The key part to the checkout conversation to me is not being able to automate and regression test but exploring with the client how a checkout can work what business rules apply for goods over weight / price etc. Then capturing this in a format that retains its value.

@jamescowie Thanks for your comments. Thanks also for suggesting a target area where the details as you mention are very important.

Because we were describing a 'conference' and not something like a shopping cart it is as you say difficult to understand what IT is. Perhaps I should have called it something like Attendee Session Selector under a context of Conference?. Normally IT is the part or component of the system that you are describing. So in the example you mentioned it would be Shopping Cart it would be easier to see what IT is. Or it might be Product Page or might even be Add to Cart Button.

Indeed the focus switches from the user to the system component.

It would be interesting to compare the 2 approaches in something like a shopping cart. So thanks for the suggestion.

You both mentioned less detail, but I fail to see what necessary details were missing? I did however notice that some of the details in the Gherkin were duplicated which I personally found harder to read.

So on a Feature File level alone I think we can both see (I hope) that there are 2 approaches and both valid yet take a different perspective.

I can't help but notice though that when these are actually implemented as tests, the Gherkin based approach will create 7 steps where ShouldIT? would create 4 tests. The ShouldIT? tests created are tests that can be run stand-alone in a technology that you would expect to already exist there anyway - such as PHPSpec, Jasmine or even PHPUnit. The step definitions I feel do not really have much context outside of the Gherkin based testing tool that might running them - at least I have never seen anything yet that suggest otherwise.

All good food for thought, the discussion is meaningful.

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.

@mackstar the missing details are:

1. A thing called Slot representing period of time
2. A thing called Track representing a numbered conference track
3. A thing called Conference that must be named and should have a specific amount of tracks
4. A thing called Talk that always have a name and could be scheduled for a specific track and slot at the conference
5. A thing called Personal Schedule
6. 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.