Test Driven Development, Geting Started!
In this post, you will know the difference between TDD, DDD, KDD, and BDD
Test Driven Development (TDD)
- Test-driven development is a development concept when the tests are written before the code. In practical, Developer start the development process by writing unit-test before writing actual code implementation.
- By doing this, we ensure that However the code implement, It’s not affecting the final goal.
- TDD was introduced by XP (Extreme Programming) is an agile software development framework
TDD Cycle
After each test, refactoring is done and then the same or a similar test is performed again. The process is iterated as many times as necessary until each unit is functionally working as expected
Example of TDD
Given the below requirement:
- The password should be between 5 to 10 characters
To do this in TDD style, we will start by writing the unit test to cover this requirement we should do the below :
First, we write the test code :
Actually “PasswordValidator” class not created yet so in case of executing the “TestPassword” the test will fail.
Now we will write our code which covers the mentioned requirement
Now we will run the test by executing the “TestPassword” class, the test will pass as the password length ≥5 && ≤ 10 (ABC123), in addition, will should try another case for example we should try with password length < 5 , and >10 to make sure that our code works fine.
Data-Driven Development (DDD)
- Data-driven development is a style of development where the data is entered into a database or in an excel spreadsheet and referenced in the automation.
- This allows automation engineers to have a single test script which can execute tests for all the test data in the table/spreadsheet, ..etc.
Why Data Driven Testing?
Consider that we want to test the system login function with multiple input fields with 1000 different data sets, to test this we can take the following different approaches :
- Create 1000 scripts one for each dataset and run each test separately one by one
- Manually change the value in the test script and run it several times
- Import the date from a the data source the use it one by one
In the three previous approaches the first, second approaches are laborious and time-consuming, therefore it is ideal to follow the third approach
Data Driven Testing Example
- Create an excel/CSV with the input test date like the below :
2. Create test script :
Keyword Driven Development (KDD)
Keyword driven development is a style of development where the keywords are entered into a database or in an excel spreadsheet and referenced in the automation.
It’s important to note that the keywords are mapped to a function.
Example : Login
In this case our keyword is ‘login’ and we will map it to a function fnLogin,This function will contain code logic for login functionality.
KDD Components
- Excel Sheet: will contain the keyword, The keywords can be arranged horizontally or vertically as per your wish
- Function Library: read the excel sheets and call the different functions based on the Keywords
- In the Keyword Driven Framework, the operations of the function library can be broadly classified into the following two types:
Application Related Flow: the function library contains functions such as Login and Logout which are actually a part of the application under test
Framework Related Flow: the function library contains functions that are not directly related to the application but related to the framework such as the functions which read keyword from excel
- Data Sheets : to store the test data that will be used in the application
- Object Repository : contain the page objects selectors
- Test Script: In the keyword driven framework, the keywords, and the flow of the test case are actually specified in the excel sheets since the flow of the test case is mentioned in excel sheets, the actual test script will not store the test case flow. Hence the test script will not be used the way we do it in other framework types such as functional decomposition framework which create the functions and then save them in the function library.Then we will create a test script where we will call all these functions one after the other
So in this case, the test script would be used as a driver script whose sole purpose would be to pass the control on to the function library
KDD Flow
- Test script will call the main function library
- The function library open the excel sheet and reads the first keyword associated with the test case
- The function library calls the function associated with this keyword
- The function then performs all the required actions on the application that is being tested
- Control returns back to main function (in Step 2) which then reads the next keyword. Steps 2 to 5 are repeated till all the keywords associated with a particular test case are called
Behavior Driven Development (BDD)
- Behaviour Driven testing is an extension of TDD. Like in TDD, in BDD also we write tests first and then add application code. The major difference that we get to see here is tests are explained as a behaviour of the application and are more user-focused
- The primary reason to choose BDD as your development process is to break down communication barriers between business and technical teams
- BDD has its own evolution from the days it was born, started by replacing “test” to “should” in unit tests, and moving towards powerful tools like Cucumber and Behat, which made user stories (human readable text) to be executed as an acceptance test
- The idea of story BDD can be narrowed to describe features in a scenario with a formal text, use examples to make abstract things concrete, implement each step of a scenario for testing and write actual code implementing the feature
- By writing every feature in User Story format that is automatically executable as a test we ensure that: business, developers, QAs and managers are in the same boat
- Each feature of a product should be born from a talk between business (analysts, product owner), developers and QAs which are known in BDD as “three amigos”, Such talks should produce written stories there should be an actor that doing some things, the feature that should be fulfilled within the story and the result achieved
We can try to write such simple story:
As a customer I want to buy several products
I put first product with $600 price to my cart
And then another one with $1000 price
When I go to checkout process
I should see that total number of products I want to buy is 2
And my order amount is $1600
Now to execute this story we need to transform it to correct model software , so Cucumber introduced a special language for such stories called Gherkin. Same story transformed to Gherkin will look like this:
Feature: checkout process
In order to buy products
As a customer
I want to be able to buy several products
Scenario:
Given I have product with $600 price in my cart
And I have product with $1000 price
When I go to checkout process
Then I should see that total number of products is 2
And my order amount is $1600
Cucumber, Behat, and sure, Codeception can execute this scenario step by step as an automated test. Every step in this scenario requires a code which defines it.
To learn some more about Gherkin format and how to execute it with Codeception check this link https://codeception.com/docs/07-BDD
If you like the concept of Behavior Driven Development or prefer to keep test scenarios in human readable format, Codeception allows you to write and execute scenarios in Gherkin. Feature files is just another test format inside Codeception, so it can be combined with Cept and Cest files inside the same suite. Steps definitions of your scenarios can use all the power of Codeception modules, PageObjects, and StepObjects
To learn more about Codeception check this link https://codeception.com
Note: Usually, in the QA industry, you will find a hybrid of the methodologies explained above
References :