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

https://github.com/BobPalmer/RobotParts

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