Is BDD mainly used in integration test? [closed]

Question

A common story

Story: User logging in
  As a user
  I want to login with my details
  So that I can get access to the site

Given such a broad coverage, it is useless if I mock the system components such as DB in order to perform the test, so can I say that people mainly use BDD in integration test?

Answer 1

Here's my terminology.

• Scenario: an example of the user using the system, with all relevant components in place rather than mocked out. May be automated and used as an acceptance test, but the conversations between business, testers and devs are the most important aspect of BDD. Often created using the Given / When / Then template, sometimes in tools which allow for natural language capture such as Cucumber or JBehave.

• Integration test: Crosses the boundary of two components, and usually used to check the integrity of integration of those components. For instance, may be used to send messages back and forth between the client and server layers of a web interface, or to check database bindings with Hibernate, etc.. Does not necessarily involve the full stack. A scenario could be considered a particular kind of integration test. BDD doesn't really apply for most non-scenario integration tests, though you could still conceivably use the Given / When / Then template.

• Unit test: An example of a consuming class using another class, usually with collaborators mocked out. May also be an example of how a consuming class delegates work to its collaborators. That's how we talk about it in BDD, anyway (you can do BDD at both levels). Can also use the Given / When / Then syntax.

• Story: A slice through a feature to allow us to get faster feedback. The behavior of a feature may be illustrated with several scenarios, and these can also be used to help slice up the feature. Often illustrated with the As a... I want... So that... template, or the In order to... as a... I want... template of Feature Injection.

• Feature: Features represent the way in which users will use the capabilities we’re giving them. This is the stage in which we start defining the concrete implementation and UI. A feature may be a web page, part of a web page, a module in a windows UI, part of an app, etc.

• Capability: Something a user can achieve with the system, or which the system can achieve. Ie: A user can book a trade, the system is secure enough to withstand hackers. Phrasing scenarios at this level helps them be independent of the UI and keeps them in the language of the business.

Hope this helps.

Answer 2

Your example is a user story, which describes acceptance test. Acceptance tests could have end-to-end scope, but not necessarily. Core difference between acceptance and integration tests, is what they are focused on. Acceptance test is business-focused and could be written/read by non-technical person (customer). On the other hand we have development-focused integration tests, which simply verify that two or more components could work together.

Back to BDD. It could be used in acceptance testing (feature level) and unit testing (code level). There are even different tools for different levels of BDD:

• SpecFlow (acceptance testing)
• NSpec, NBehave (unit testing)