What is BDD?
BDD is defined on Wikipedia as follows:
BDD is a second-generation, out-of-band, pull, multi-stakeholder (stakeholder), scalable, and highly automated agile approach to the process of using. It describes an interactive loop that can have well-defined outputs (that is, results delivered at work): Software that has been tested.
In a nutshell, BDD, or behavioral-driven development, is to implement these behaviors by communicating the needs of the product manager, defining the behavior (behaviour) that the software needs to meet these requirements, and then using these behaviors as drivers (driven) to write product code. (Development). The emergence of BDD is to solve problems that are often encountered in test-driven development, such as where to start testing, what to test, what not to test, and so on. For more information, see Introducing BDD in Dan North.
Problems faced by BDD practices
The first thing to do with BDD practice is to address the following questions:
How do you implement a test that describes system behavior (business value), non-technical, and readable?
How do I get this test to be executable?
The industry has answers to these questions, and JBehave, Cucumber,concordian and other BDD frameworks have emerged to solve the problem. These BDD frameworks each provide a set of DSL (Domain-specific-language) that developers can use to describe business requirements, for example,
Precondition:
User A account balance 1000 yuan
User B account balance 200 yuan
scene:
User A login system
to User B transfer 500 Yuan
User A account balance should be 500 yuan
User B Zhuang Hu Lüliang balance should be 700 yuan
At the same time, these frameworks are dependent on webdriver (such as Selenium-webdriver,watir-webdriver), the BDD framework uses Webdriver to invoke the browser's interface, simulate user input, and read the content displayed on the browser page for validation.
Here's a complete example to see how to use these tools for BDD practice.
Cucumber and business value
In behaviour driven development, the first step is to subdivide the requirements into multiple tasks, taking the most common user login function as an example, which can be divided into the following tasks:
User name password match, login successful
User name or password does not match, logon failed
BDD emphasizes "each test needs to reflect the business value", so you can implement these two tasks into two scenarios:
Feature:user Login
Background:there is a User with the following login detail:
| Email | password|
| my@example.com| Test |
Scenario:login succeed
Given the user Login with the following detail:
| Email | password|
| my@example.com| Test |
Then The user should login succeed
Scenario:login failed Given The
user login with the following detail:
| Email | Password |
| my@example.com| Wrongpassword |
Then The user should login failed
In fact, the code above is a test scenario that uses Cucumber's DSL description, almost by following a certain format of English, and even product managers and business analysts who don't understand the code can communicate smoothly through this document and developers. Using cucumber to describe the different scenarios of a requirement, it also expounds the business value of this requirement from different angles. The goal of Cucumber is to write executable, able to express business value documents. There are similar frameworks and Concordian,jbehave.
The immediate question is: how do I get the document to execute? Cucumber provides a mechanism for translating business logic into executable code-"Step definition". Take a look at the following example:
Given/^the User Login with the following detail:$/do |detail|
#omitting code ...
End
This step definition will match the following step:
Given the user login with the following detail:
| Email | password|
| my@example.com| Test |
When the cucumber feature is executed, the code in this step definition is executed. The next question, then, is how to open the browser like a real user, enter a username password, and click the Submit button to verify that the login was successful. At this time, the Webdriver appeared.