I understand it is better to automate BDD specifications below the user interface whenever possible.

For example and quoting from Gojko Adzic's book: Specification by Example:

Don't check business logic through the user interface

My question is then: What are the specific use cases when using the UI layer does make sense in the context of BDD?

  • I haven't actually heard this recommendation, in the context of BDD or anything else. Is it possible that the writer might mean "don't check business logic only through the user interface?" Because typically if you have UI tests, you'll be doing end-to-end tests of the same business logic that you're already testing via unit tests. Or maybe he means "don't check internal business rules (i.e. that the user doesn't know or care about) through the interface"?
    – Aaronaught
    Sep 7 '13 at 16:19
  • Thanks for your reply. Apparently and according to the author, the idea is to avoid going through the UI layer whenever possible. Also a unit test typically uses mocks in order to isolate the class under test whereas end-to-end tests will hit repositories and the backend. I just wondered when going through the ui layer was applicable and recommended.
    – balteo
    Sep 7 '13 at 16:35
  • This might be of interest to readers of my post: (stackoverflow.com/questions/10356005/…) but it does not fully answer my question...
    – balteo
    Sep 7 '13 at 16:37
  • Huh, well, it's certainly an interesting conversation. I'm used to having tests that cover the units, the controllers or REST API, and the user interface. They all catch very different categories of bugs. It's hard to give specific examples because I have a completely opposite perspective: Try to make as many end-to-end tests as possible work through the UI, so that they're easy to follow, understand, and record by QA analysts and product owners, and only work with APIs or databases when the UI is too fickle or cumbersome to work with. It works for us. shrug
    – Aaronaught
    Sep 7 '13 at 17:04

There are two distinct cases that might fall under the category of "using the UI" that you mentioned above, and they have different cases when it would make sense to use them:

1: specifying something using the UI concepts, language or elements - specific use cases that would justify this would be important rendering logic (think about twitter's link display - eg if the entire link is less than 100 chars, display the link, else shorten it, or positioning elements on the screen depending on how many links an article has etc) or critical/highly risky user interface specific workflows (navigation, dynamic menus etc). "critical/highly risky" is the crucial thing here, because it's very easy to think about the UI and one of the biggest problems new teams typically have with BDD style specs is to overdo them from the UI, describing stuff that's not that important long term

2: just automating tests through the UI while the spec is still talking about underlying functionality - eg the spec talks about free delivery, but the underlying test automation uses selenium to open a browser, load the web site, purchase books, go to checkout etc (similar to what I've described in the Three Layers pattern http://gojko.net/2010/04/13/how-to-implement-ui-testing-without-shooting-yourself-in-the-foot-2/). Specific use cases that justify this are where the system is designed in such a way that the risk is spread across the user interface, and testing below the UI would not provide enough confidence to stakeholders. This is mostly a legacy system design issue, and I've used this approach when retrofitting BDD-style tests to a legacy system before an important change, or when extending a legacy system that contains a lot of risk or important logic in the user interface layer. If you have to do this on a new system, that's typically a sign of risk not being localised and might point to problems with the system design.

Outside the scope of BDD, but related to tools that people often use for BDD, writing tests (not specs in the spec-by-example sense, but just automating regression tests) through the user interface also makes sense in the cases where the risk is spread across the different layers, so excluding the UI from the test would not provide enough confidence, or when you want to automate a small number of selected face-saving tests that additionally de-risk critical workflows throughout all components. As an example, a major media company had roughly 10 such tests for their primary web site. These tests were automated using cucumber, because that is what developers could maintain easily, and they were very flaky - almost any UI change broke them, but because there was just 10 of them the maintenance costs weren't that high. Those tests were described in UI terms and they executed through the UI to ensure the widest possible coverage. They were used by developers as a quick check they had to do before saying that they are done with a piece of work, in addition to the technical unit tests and BDD-style .

As you mentioned, generally it makes a lot of sense to avoid coupling the user interface and business logic (not just for spec or testing purposes, but for maintainability as well - the UI tends to be the most volatile part of the system).


My opinion is that BDD verification in the UI makes a lot of sense if the person writing the test isn't the person who wrote the application. Or if you just want more thorough testing to prove that when a user goes to your application, it will actually work and you really want to know that a relative path to an ajax service is absolutely not broken (or similar things unit testing/BDD in the backend can never find). This can make deployments a lot easier because you aren't sitting there wondering if hundreds of pages actually work after you push to the server.

You asked for a specific example, so here goes.

My old colleague made a web application called a "robot parts" store that is available on github


It is tested in just about every way you could test an application. He has some coded UI tests in there that are very BDD (although not using a BDD specific framework)

And he does test the back-end with BDD (specflow)

Looking through this application may be helpful for you to see where the lines are drawn between UI/backend and unit tests/BDD.

Here are a few tests where the UI is tested in a BDD manner

  • I see... What you say about ensuring the app actually works and the example of the path to the ajax service is interesting indeed. However, one could say that the comprehensive UI tests you are advocating for is not real BDD: you are not testing behavior but rather technical aspects of the UI. What do you think?
    – balteo
    Sep 9 '13 at 16:57
  • It's testing both behavior AND technical aspects of the UI. The second you combine more than 2 dependent steps in a UI test, how is that not BDD? The "problem" is, there's the argument that you may as well do javascript unit testing as to not be testing many things at once. The link I posted is definitely BDD in a UI test because it's executing repeatable steps, expressed as behaviors, and asserting the result. It could fail because of a jquery selector being wrong, true, but it absolutely tests behavior.
    – brian
    Sep 9 '13 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.