- Test-Driven Development (TDD)
- Behavior-Driven Development (BDD)
- Acceptance Test-Driven Development (ATDD)
These are the buzzwords you are very likely to be confused by if you are just starting off your journey into the world of software testing. I have used (vs) in this case not as a comparing tool of which one you should choose, but as a way of shinning a light on their differences and when they can be used.
In reality they kind of blend into each other, we write BDD using TDD and before we start either BDD or TDD we first write ATDD to help define our objectives and what it really means to say we have achieved our goal. So as you can see it is not a matter of one or the other, but a blend of all three.
Time to see this with an example, first we need a feature.
This is a new feature we want to implement, an e-commerce site wants the ability for its customers to be able to add product items into a shopping basket.
We are keeping this simple so it is easy to follow, the first thing we need is to write our Acceptance Test or Acceptance Test-Driven Development (ATDD).
This is to test that we have indeed delivered the feature as requested, the acceptance test is written with the customer/product owner, programmers and testers, and it is done before any work is started, we are going to write this test in a GIVEN, WHEN, THEN format.
A typical acceptance test would be in the following format:
Given (setup): We specify the state of the system
And (extension): We can build on the previous step
When (trigger): We perform some form of action
Then (expectation): What we expect as a result of When trigger
Let's write our acceptance test using the Given, When, Then steps to cover our feature:
Given we have some products listed in store
When customer clicks on 'Add to Basket'
And customer visits the shopping basket
Then we expect product to be visible in shopping basket
When this feature is completed, every line of this acceptance test above will be test to make sure that they behave as agreed, this forms a sort of contract between various stake holders in this project, now the programmers can take this acceptance test and begin work.
Behaviour Driven Development (BDD)
With acceptance test written, now it is time to dive into BDD, This is sometimes referred to as the outside in testing, firstly it is an automated test, where we write code that simulates a real user, by visiting any given page, and filling in forms clicking on buttons or links and finally expecting a result.
The BDD steps below is written using Rspec / Capybara testing framework for Ruby programming language.
RSpec.feature "Shopping Basket Management", :type => :feature do before do create(:product, name: 'Blue T-Shirt') end scenario "Adding item into basket" do visit product_listing_url click_link('Add to Basket') visit shopping_basket_url expect(page).to have_content('Blue T-Shirt') end end
We have now written our BDD! this test essentially makes sure that we are fulfilling the criterias from our acceptance test, but this time it is written in code, lets examine what this code actually does although I am sure you can figure it out, this is one of the reasons people love Ruby, it reads like plain english.
1) We are creating a new feature test with one scenario "Addding item into basket"
2) Before this scenario runs, we want to create a product with name 'Blue T-Shirt'
3) We then visit the product listing url, where we expect to find and click a link called 'Add to Basket'
4) We then visit our shopping basket url, and expect to see the product we added 'Blue T-Shirt'
In summary BDD tests the behaviour of a feature, just like a real user would, it tests multiple components together, in this case we are testing Products interaction with Shopping Basket and a Customer.
When we run this test we expect that it will fail, because so far all I have done is draw the expectations on a note pad, to get it to pass we need to actually write the relevant HTML code and make all the links work as expected, I am not going to cover that in this article as I want to keep things simple and only focus on testing side of things and not the implementation.
Test-Driven Development (TDD)
This simply refer to the method of writing a test first before implementing any solution, first making it fail and then implementing a solution that will make it pass.
If you think about it, that is what we have done throughout this article, first we wrote ATDD which outlined some acceptance tests, without a solution this test fails, we then went ahead and created BDD where we wrote some automated test, this again is another form off TDD.
If you then go ahead and write the code that lists all products, add a link to add products to basket, when we run our BDD test it will pass, and then we run our ATDD that too will pass.