Why Should One Integrate BDD?

You are here

Where does one use BDD?

MindUsage of BDD can be a splendid way to capture the business requirements as well as acceptance criteria’s of a higher level. It is a good thing to use BDD when you want the app to precisely what it was meant to.

Let’s try to figure out the advantages and the disadvantages of BDD usage in various process parts.

UI and BDD

When your team is using this approach they may achieve implementation of definitions that will be executed against the web app that is running. Such a goal is usually achieved with usage of such tech as HtmlUnit or Selenium. Thus every scenario will be loading web pages, clicking on various links as well as filling and submitting various forms. Expect for that it will also be making averments about the HTML docs and all resources associated which are being returned.


  • The behavior is averted all across the app.
  • The BDD approach is good for both driving UI development and the application logic.


  • The feature steps can indeed be executed against the application only after it is built and deployed. That can make the development process quite slower.
  • The UI that is web-based often tends to be the most unstable part of the web app. Thus due to the fact UI may be tweaked the feature steps can be broken. From this it may appear that the behavior is lost. Step Definitions to tend to become quite fragile.
  • The BDD on this level can chance UI rapidly if user experiences or graphic designs are being used.
  • Writing BDD step definitions might appear to be quite a challenge on this level. This is happening because testing on this level is requiring lots and tons of boilerplate code written.

Web Protocol and BDD

This approach is all about the step definitions executing the Web Protocol that is used for the apps interface directly. As an example we may think of it as of something that will be making the steps do the HTTP calls right to the app. It will also be making sure that the results returning are accurate and expected.


  • There will no longer be no need to concern about the web pages’ complications such as JavaScript, etc. these things are actually better to test in a very dedicated set of UI tests.
  • It will go splendid with result-full or other related web services. They will even return in structured data rather than HTML docs.


  • The feature steps still can be executed only against an already built and deployed app.
  • Construction of complex consistencies of requests can be quite challenging if you actually want to simulate things as Ajax. This may be more complicated then testing UI.
  • Averring against the HTML that has returned may be more challenging than using these assertions in frameworks such as Selenium in the UI layer.
  • If you have a desire to build and test at this layer you will still need a set of UI tests.

Controllers and the BDD

This kind of an approach allows us to ignore UI and the view of the app parts. Rather than the mentioned the team will have to write the whole app from the controllers or snippets layer down. So what will be used in order to generate the correct view? Step definitions will be written in a way that is summoning (no, not the spirits of IT blessings) the controllers or snippets with requests and asserts that will be pre-defined.


  • Features now may be tested as a part of the phase of the test. There is no need of deploying.
  • Testing at this exact level is more stable.
  • It is fairly simpler in most cases just to call upon an asset on the code level than an entire UI level.


  • In order to simulate the requests in a proper way the framework that is chosen will need an impressive set of various testing features.
  • Lots of effort and integration dedicated logic of the tests will be spent on UI rather than on the assertion against the business rules.

Services and BDD

This step is usually the testing against the service code. Yet it is plausible that this step will also need step definitions to be properly written against the objects of the domain level. This is when testers determine the apps’ business behavior and UI is of least interest.


  • Features now may be tested as a part of the phase of the test. There is no need of deploying.
  • Code will be quite more stable that on other levels.
  • Step definitions shall be much simpler.
  • The testing is finally done against business rules.
  • Less specific tools and support from frameworks is required.


  • Testing on this level will be less app flow oriented.
  • Developers need to be of iron discipline in order for no piece of business rules or logic or behavior leaks into the controllers’ layer.

Thus where is all this headed?

After seeing how BDD may be applied on each layer, seeing the strong and the weak sides of the process it is now only up to you to decide whether you are willing to implement it. This information is likely to be used from the customers (the business) side while negotiating about the requirements. Thus you will know the plusses and minuses of what you are being offered.