Outside-in BDD (with Specflow)

Question

I'm new to BDD, but I found it very interesting and want to develop my next project using BDD. After googling and watching screencasts I still have lots of questions about BDD in real life.

1. Declarative or Imperative scenarios?

Most of given-when-then scenarios I saw were written in terms of UI (imperative).

Scenario: Login      Given I am on the Login-page      When I enter 'AUser' in the textbox 'UserName'        And I enter 'APassword' in the textbox 'Password'        And I click the 'Login' button      Then I should see the following text 'You are logged in' 

I found those tests extremely brittle and they tell nothing about business value of clicking on buttons. I think its nightmare to maintain. Why most of examples use imperative scenarios?

Scenario: Login (declarative)      Given I am not logged in      When I log in using valid credentials      Then I should be logged in 

If you prefer declarative style, how do you describe such stuff like 'Home page' or 'Products page'?

• Tips for writing good specifications

2. Exercise UI or not?

Most of steps implementations I saw used WatiN, White or something like that to implement scenarios from user point of view. Starting browser, clicking buttons. I think its extremely slow and brittle. Well, I can use something like Page object to make tests less brittle. But thats another amount of work. Especially for desktop applications with complex UI.

How do you implement scenarios in real-life projects - exercising UI, or via testing controllers/presenters?

• Best way to apply BDD

3. Real database or not?

When Given part of scenario is implemented, often it needs some data to be in the system (e.g. some products for shop application). How do you implement that part - adding data to real database (full end-to-end testing), or providing repository stubs to controllers?

Waiting for experienced answers!

UPDATE: Added useful links on questions.

Answer 1

1. Declaritive is the proper way, IMO. If youre talking about page .aspx file names, you're doing it wrong. The purpose of the story is to facilitate communication between developers and non-develoeprs. Non-developers don't care about products.aspx, they care about a product listing. Your system does something the non-developers find value in. This is what you're trying to capture.

2. Well, the stories tell the high level features you need to implement. Its what your system must do. The only way to really tell if you've done this is to in fact exercise the UI. BDD SpecFlow stories to me don't replace unit tests, rather they're you're integration tests. If you break this, you've broken the value the business gets from your software. Unit tests are implementation details your users don't care about, and they only test each piece in isolation. That can't tell you if A and B actually work together all the time (in theory it should, in practice interesting [read: unexpected] things happen when you actually have the two parts playing with each other). Automated end to end tests can help with your QA as well. If a functional area breaks, you know about it, and they can spend their time in other areas of the application while you determine what broke the integration tests.

3. This is a tricky one. We've done a hybrid approach. We do use the database (integrate tests after all test the system functioning as one thing, rather than the individual components), but rather than resetting configurations all the time we use Deleporter to replace our repositories with Moqs when we need to. Seems to work ok, but there are certainly pros and cons either way. I think we're still largely figuring this out ourselves.