Behavior-driven development (BDD) is a software development process in which teams create simple scenarios on how an application should behave from the end user's perspective. The goal of implementing BDD testing is to improve collaboration between key stakeholders, such as developers, testers, product managers, and business analysts, by writing test scenarios in an easily-decipherable language - Gherkin. The BDD testing framework promises to address the need for automation that many agile development shops have, through free and open source frameworks like RSPEC, Cucumber, and Specflow.
Yet behavior driven testing isn't designed as an automated testing tool at all. Instead, Behavior Driven Development describes a collaborative process, and BDD tools help enable the movement. Having the code in something like English makes it easier for customer, tester, and programmer to collectively design the examples that will drive development.
Collaboration We've had test automation in one form or another for decades - but it was almost always done by a test-automator alone. When the results of the test did not match what the automator expected, the programmer and tester had to argue about who was "right"; then bring in the product manager to have the same conversation again. BDD programming prevents problems by thinking of the behavior as examples, and having (at least) all three roles represented when defining the examples.
Here's how it works: Before any programming begins on a story, everyone gets together to talk about what the customer wants in the next release and how a new set of features will add value to the product. After this, development goes off to make product and occasionally deliver testable bits. If they have time, the product group occasionally checks in on what is being created while working with customers on what they might want next. Usually though, their focus is on the next release.
That means that for each story (or feature or requirement) a small group gets together to acceptance criteria (some call this "rejection criteria", which we'll explain later) for that feature. The flow of work potentially changes from business to development to test to something where the three groups all work together until a feature is shippable.
TestLeft allows you to quickly translate BDD requirements written in Gherkin into actual functional test steps for anyone to understand, automate, and troubleshoot. And, of course, there is the advantage that Behavior Driven Development in the gherkin language looks a lot more like English.
TestLeft can be embedded into standard IDEs, including Visual Studio, IntellJ IDEA, and Eclipse, for developers and advanced testers to start testing earlier in the software development lifecycle. TestLeft can also stand alone, allowing you to create automated tests for any IDE. Without ever leaving the environment you are in, you can accelerate shifting left by running functional tests sooner.
TestLeft empowers advanced testers to use any BDD framework for C#, Java, or Visual Basic .NET. With our sample test projects, you can quickly create a true behavior-driven development (BDD) workflow with popular frameworks such as Cucumber, SpecFlow and JBehave. With TestLeft, you can use any feature files written in Gherkin with built-in TestLeft methods and classes.
With TestLeft, you can quickly recognize objects with our UI Spy, create code with our application model or page generator, and run functional tests against Gherkin requirements. Our robust UI spy will auto-generate your application model in just two clicks so that you can quickly build accurate step definitions in Java or C# to enable a true Behavior-Driven Development process.
The classic way to describe tests in BDD workflow is to put then in the form of Given, When, Then. Given describes the current system state or a set of preconditions for a test. BDD automation framework is a behavior test where the behavior or set of test steps that your test will perform. Then is where assertions, or the expected changes from your test, are described. The behavior driven development example of a test is done in something very close to English, which might look like this:
GIVEN I am in a Amazon.com cart with 1 copy of The Shape of Actions WHEN I apply a 10 percent discount code THEN Total = total - (total * 0.10)
This part of the test would probably be written by a product manager or maybe a non-technical tester. Interpreters can't work with English though, code has to be written to make that set of descriptions useful, so the roles gather to create the code above, which is actually in Gherkin, a programmable language. After the meeting the programmer can write the ruby (or Java, or .net) code that the Gherkin will call.
Rather than calling something in this format a test, people that do behaviour driven testing call this a scenario or a specification. Behaviour Driven Development is not a testing technique. Testing is part of a product strategy that can help to discover quality related information that might affect the future of the product. BDD test automation on the other hand, is a development strategy, or maybe a product management strategy if you look at it through the right lens. It acts as a reminder to developers about the value of what they are building and helps them to build the right thing the first time around. (The automated checks that remain after behavioral driven development testing is done can be part of a strong risk management strategy.)
Even though behavior driven development framework and BDD testing tools can create a nice middle ground between technical staff and the business units, there are a few things to be aware of. Behavior Driven Development is often used to create a set of acceptance tests. The big gamble is that the product should be releasable as soon as all of these tests pass. Given/When/Then tests check only the "then" condition, and assume "... and nothing else bad happens." That can be a big assumption to make.
I like to flip the idea on its side, and think of BDD process as rejection criteria. That is to say, while a failing test guarantees the software is not ready to ship, but a passing test does not mean the product is ready to release.
Also, keep in mind that behavioral driven development scenarios tend to be dead simple. They begin with a specific system state and then perform simple operations in the same order ever time. Something like navigate to amazon.com, add the book Tacit and Explicit Knowledge to your cart, and then verify that the book is in your cart along with all the appropriate information.
A normal user might do something more along the lines of searching for a book, reading the reviews, adding the book to the cart but accidentally adding 2 copies instead of 1, leaving the cart to browse more before returning to the cart to see that the wrong number was added, and finally changing the quantity so that there is only one copy. Even this is probably a simple example that ignores everything a person does while trying to buy a book on Amazon.
Be careful not to get lulled into a false sense of comfort from reports saying all the checks pass. You will probably want to know more before making important decisions like when to ship. The next step is to try a small experiment with your team to see if this style of development can add value. To see how BDD automation framwework can help your team, try TestLeft free for 30 days