3

Yesterday I went to a great presentation by Gojko Adzic about BDD. I might have missed one or two things he said so here is one question that hopefully will clear somethings up for me.

Often when you see BDD example online they have included steps in the UI. In a gherkin language you can often see something like: 

Scenario: Successful booking
    Given I am on the page ...
    When I enter the following ...

Or something like that.

My question is, does that really have with BDD to do? Shouldn't BDD be targeted towards the domain and then you have those kind of tests as UI or regression tests. What I am thinking about is something like this use gherkin syntax to describe somekind of booking system:

BDD Spec:

Scenario: Successful booking
    Given I am an authenticated user
    When I place an order with the following items
        | item  | price ($) |
        | book1 | 5         |
    Then I should expect to pay $5
    And I should get a confirmation mail of my order

Note that I am not mentoning the UI at all, I am only describing how the domain works and this test should be run on every build. Then you can have your UI test (also gherkin):

Scenario: Successful booking
    Given I am logged in on the site
    And I go to the page for item book1
    And I click add to basket
    Then I should have a basket with 1 item and $5
    When I click checkout
    Then I should get to the checkout page

and it continues, maybe it should be separated into two or three scenarios but that is not the point. Theses kind of tests are heavier to run and should probably only be run on nightly builds. The point of the question is still: Should you separated you BDD specs from your UI/regression test.

Tomas Jansson
  • 22,767
  • 13
  • 83
  • 137
  • 3
    Since you are referring to Gojko Adzic, let me give a quote from his book "Specification by Example": "Don’t get trapped in user interface details. The user interface is visual, so it’s easy to think about. I’ve seen projects where teams and customers spent hours describing navigation menu links. But that part of the user interface carried virtually no risk, and that time could have been spent discussing much more important functions. [...] – Vagif Abilov Oct 26 '11 at 07:47
  • 1
    (quote continues): "Instead of dwelling on user interface details, it’s more useful to think about user journeys through the website. When specifying collaboratively, invest time in parts of the specifications in proportion to their importance to the business. Items that are important and risky should be explored in detail. Those that aren’t that important might not need to be specified so precisely." – Vagif Abilov Oct 26 '11 at 07:49
  • To summarize: BDD specs don't need to be expressed in terms of UI. Moreover, UI tests are more often end-to-end tests which is not the same as a feature specification. – Vagif Abilov Oct 26 '11 at 07:51
  • @Vagif Abilov: You should write it as an answer, and I am glad I got the book yesterday... but I didn't have time to finish it last night :) – Tomas Jansson Oct 26 '11 at 08:05

2 Answers2

2

BDD boils down to collaboration between QA other non-technical people with the developers using native language as definitions for the functionality. So from this perspective, both of your examples are likely to be understood as a feature by the stakeholders.

But in general, the more abstract you can make the "story", the better. The difference,or potential issue, isn't so much about mentioning the UI, but potential assumptions and discussions about the layout. The initial workflow of the application is likely to change, so changes in the feature definition might require new discussions with the staeholders. Talks that might not really be required if the goal remains the same.

That said, practicality will come into play very quickly. An ambiguous feature definition will require a more exact definition for the ui, and that is in turn turned into a step definition or tests written with other UI testing tools. Writing the actual step definitions for the feature files is the hardest part so writing new scenarios is rather quick once you have a comprehensive set of step definitions in place. Not reusing these in UI tests seems like a waste, so we use the same set for UI tests.

We separate the UI tests only in the sense that not all scenarios are discussed with the stakeholdes. The most important ones tagged, and each feature has one or two scnearios tagged and the rest are UI tests. Also, sometimes the feature files are not written by the person writing the step definitions, so this allows the UI test writer to be less knowledgeable about the specifics how the UI operations are implemented in the framework in use.

Tatu Lahtela
  • 4,514
  • 30
  • 29
0

Trying to separate out domain and UI tests is not recommended.

The big advantage of using Cucumber is that your specs (tests) can be read and understood by non-technical stakeholders. Those people probably aren't too concerned about user interface details.

So a good approach is to simply push the UI stuff down a layer to within the step definitions, e.g.

Given /^I place an order for "([^"]*)"$/ do |item|
  visit catalog_url
  click_link item
  click_button "Add To Basket"
  click_button "Submit Order"
end
Andy Waite
  • 10,785
  • 4
  • 33
  • 47
  • 1
    But do non-technical stakeholder care about what link or button you click? The stake holders care about the domain. They care about building up an order, placing the order and getting paid for the order. – Tomas Jansson Oct 26 '11 at 12:59
  • 1
    That's exactly what I'm trying to illustrate - this is the step definition. Only its name "Given I place an order for X" appears in the feature file, so your stakeholder won't see the implementation details. – Andy Waite Oct 26 '11 at 16:34
  • Why is not recommended to separate the domain and UI tests? – Tomas Jansson Oct 26 '11 at 20:14
  • I mean in terms of Cucumber features. In other words, there's little point using Cucumber for something that no business stakeholder will read, as it just adds an unnecessary overhead. However, it's fine to have other kinds of tests in addition to the Cucumber stuff, e.g. for views or JavaScript, but you'd write them using RSpec, QUnit, etc. – Andy Waite Oct 26 '11 at 22:30
  • 1
    What about stakeholders who care about the visual appearances? I'd lean toward complementing the BDD scenarios with wireframes to further define the visuals, but it's a realistic question to ask either way. – Brenden Feb 26 '14 at 23:28