I’m currently getting into BDD/Cucumber and I ask myself: On which levels is it good to use?

There are the test levels (from the testing pyramid):

• User Interface
• Integration
• Unit

You can apply tests on various levels and fields in the application architecture:

• Presentation layer
  • Rules (how are business rules reflected in the UI?)
  • Workflow (how does the user get where he wants?)
  • Technical (how does the UI aid the user in getting where he wants?)
• Service layer
  • Rules
  • Workflow (e.g. session handling)
  • Technical
• Data access layer
  • Service gateways
  • Persistence

My current impression is:

Cucumber/BDD doesn’t restrict WHAT you test with it. But best it is used for business rules. To test them you would mostly want to use unit and integration tests. UI tests can also be run with BDD, there are use cases out there. But my impression is that business rule tests are better not done on the UI, instead you can keep with just testing workflow (e.g. view transitions) and the technical level (e.g. data transfer and interactions between view and presentation logic or services) there, otherwise you would have to test business logic on both, UI and integration/unit level.

So why do I have this question here? There are contradictions in what I read so far…

• I thought Cucumber/BDD is really just for testing FEATURES (so basically business logic?) and not for stuff like “when I click here, and i enter X, and I click OK” (workflow)?
• I also read a lot that BDD is “of course” meant for end2end tests (my impression is that it doesn’t have to)
• On the other side I made quite bad experience with end2end tests (as a consequence I think you should just use them for a very small amount of UI test cases, basically sanity/smoke tests)

So you can see this is about the basic questions of how a test suite is organized and architectured with BDD. What is your best practice? What do you use BDD/Cucumber for and how? (Testing levels, architecture levels)