Databases
StackOverflow2013
Postsdbo
POShould your BDD specifications be separated from your UI tests?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POShould your BDD specifications be separated from your UI tests?
    primarykey
    data
    text
    <p>Yesterday I went to a great presentation by <a href="https://twitter.com/#!/gojkoadzic" rel="nofollow">Gojko Adzic</a> 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.</p> <p>Often when you see BDD example online they have included steps in the UI. In a gherkin language you can often see something like: </p> <pre><code>Scenario: Successful booking Given I am on the page ... When I enter the following ... </code></pre> <p>Or something like that.</p> <p>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:</p> <p>BDD Spec:</p> <pre><code>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 </code></pre> <p>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):</p> <pre><code>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 </code></pre> <p>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.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USTomas Jansson
    plurals
    1. This table or related slice is empty.
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POShould your BDD specifications be separated from your UI tests?
      1. USjvervoorn
      1. VTFavorite
    2. VO
      singulars
      1. POShould your BDD specifications be separated from your UI tests?
      1. USChandu
      1. VTFavorite
    1. COSince 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. [...]
      singulars
      1. POShould your BDD specifications be separated from your UI tests?
      1. USVagif Abilov
    2. CO(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."
      singulars
      1. POShould your BDD specifications be separated from your UI tests?
      1. USVagif Abilov
    3. COTo 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.
      singulars
      1. POShould your BDD specifications be separated from your UI tests?
      1. USVagif Abilov
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload