Test Driven Development, Geting Started!

Sherif Rashed
tajawal
Published in
7 min readMay 24, 2018

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

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.
Data Driven Testing Framework

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

  1. Create an excel/CSV with the input test date like the below :
DDD Table

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

KDD Components
  • Excel Sheet: will contain the keyword, The keywords can be arranged horizontally or vertically as per your wish
KDD Excel Sheet Example
  • 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

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 :

--

--