Databases
StackOverflow2013
Postsdbo
POHow do we handle minor permutations of BDD scenarios?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POHow do we handle minor permutations of BDD scenarios?
    primarykey
    data
    text
    <p>I'm loving the BDD approach to development, but I've bumped into a concern with how far to go. This comment from ThoughtWorks most recent <a href="http://thoughtworks.fileburst.com/assets/thoughtworks-tech-radar-march-2012-us-color.pdf">Radar</a> gives me pause:</p> <blockquote> <p>"The advent of behavior-driven design (BDD) testing frameworks like Cucumber, combined with browser automation tools like Selenium, has encouraged widespread use of acceptance testing at the browser level. This unfortunately encouraged doing the bulk of testing where the cost to run the tests is the greatest. Instead, we should test at the appropriate level, as close to the code as possible, so that tests can be run with maximum efficiency. Browser-level tests should be the icing on the cake, supported by acceptance and unit tests executed at appropriate layers."</p> </blockquote> <p>So here's my scenario (pun intended):</p> <p>I've got a basic CRUD app with a business requirement to filter the data displayed based on criteria the end user is permitted to select. For ease of discussion let's say it's an app for the power company, and I'm displaying current month-to-date power usage for each customer. The user of this app could narrow the data by selecting a single customer, multiple customers, no customers, or "All customers". The displayed data will change based on what they select.</p> <p>For a product stakeholder, these really represent 4 separate scenarios. However from a developer perspective they are practially identical, with the only difference being a parameter passed to the DB. So the question becomes: does the benefit of having each permutation spelled out outweigh the cost of running and maintaining them?</p> <p>I think BDD principles would probably say "yes" because the communication of the expected behavior is more explicit, but I'm not sure. It certainly has the feel to me of overkill. The scenarios would likely be a lot of copy-paste with minor changes.</p> <p>My inclination is to cover this functionality with a single scenario that captures the core business value ("when I select a customer I see the power usage data"), and then cover the other permutations with a set of non-UI-based integration tests that validate the service/query returns the correct data. Is this thinking wrong? What's the best answer to making sure these scenarios are covered, without surrendering the benefits of BDD?</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. This table or related slice is empty.
    1. USRyan Nelson
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POHow do we handle minor permutations of BDD scenarios?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POHow do we handle minor permutations of BDD scenarios?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POHow do we handle minor permutations of BDD scenarios?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

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