Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
In the past I've used BDD - Cucumber with the Gherkin syntax - for UAT (User Acceptance Testing). Is this the main area of testing for using Cucumber ? My organization also has the following areas of testing:
Is it suitable / practical to use BDD for these other areas, or is it only suitable for User Acceptance Testing ?
Although the main purpose of BDD is to enhance conversation between people involved in a project is can be used to described any level of test.
Besides UAT, one can describe an object behavior (unit test) using Given-When-Then:
The point of using Gherkin is to describe the test in English, facilitating maintenance and reuse. It is obvious the benefits of it for UAT, since the user flows can be easily describe in a high-level language.
For lower-level tests, this maybe not so beneficial because test code can describe how a small portion of production code behave in an acceptable way. A possible benefit of using BDD for all test cases is the use of the same tool throughout the whole system - but time will be needed to see this benefit.
BDD is suitable for all levels of testing, Gherkin not so much. Writing unit-tests with the overhead of Gherkin (e.g. English feature files, regular expressions and functions to execute the tests) is extra work, but work that does not have the value of conversation as only developers read them.
Describing your tests from a behaviour stand-point is very good for all level tests. Even for the unit-tests, because only testing the implementation details leads to change-detector tests, which will harm refactorability on the long run.
If you want to let non-technical/-developer roles add or change test-cases then BDD in a readable format seems to make sense. If you want to let these people also add unit-test cases I would have a look at FitNesse where inputs and expected outputs can be described in a wiki format.
For the lower level tests there are BDD-frameworks that describe the behaviour, but work more like regular unit-testing frameworks. For example Jasmine (JavaScript) or Spectrum (Java).
For the higher level tests Cucumber-like frameworks make more sense as the tests are more user-oriented. This way you can discuss requirements with the users before they are built.
Personally I gave up on Gherkin as the developers see it as extra work, the business does not read them as they like to focus only on the high-level. The testers tend to love it, but it adds extra complexity that is not worth it if the business and the developers are not in on it.
