It was interesting to see that it goes to the 'opposite direction' of what I have been thinking.
BDD is about writing specs(a.k.a test) first from a user point of view rather than the programmer.
It roughly goes like this:
- Write spec for a feature(or a scenario), and see it fail. [user view]
- Think how to make a view, write a spec, see it fail.
- Now write code for view (specs pass, now you have non functioning HTML page)
- Think how make it function, write spec for controllers, see it fail.
- Write code for controller (pass, now you have functioning HTML page without data)
- Think how to manage data, write spec for model, see it fail. [programmer view]
- Write code for model and see it pass.
- Now a feature spec will pass.
- Continue to next feature.
The steps may be omitted or expanded per case.
Given that the core concepts of BDD and TDD are not different, it doesn't matter to do unittest in BDD style.
I think the whole thing about BDD is to encourage the programmer to think of writing a spec first, rather than "implement a test after the code".
Selenium, Rspec and Lettuce will play a role in the first step: a user-level spec (or a feature) that guarantees working.
You can write a feature with lettuce, run with selenium to ensure the integration of the whole feature.
Somewhat debatable, but nice to keep in mind what the philosophy of BDD is for.