_edited_edited.png)
Test Driven Development
Test Driven Development (TDD) is a software development approach in which test cases are developed to specify and validate what the code will do. In simple terms, test cases for each functionality are created and tested first and if the test fails then the new code is written in order to pass the test and this makes code simple and bug-free.
Test-Driven Development starts with designing and developing tests for every small functionality of an application. TDD instructs developers to write new code only if an automated test has failed. This avoids duplication of code.
TDD Principles
TDD combines programming, unit testing, and refactoring, all of which leads to clean code, an easily-modified application, and an application that answers the expressed needs of the client, which remains the first priority.
TDD has three phases:
RED. First, a unit test is written in failure. Not being able to compile is a failure.
GREEN. The production code that can pass the unit test is supposed to be written as soon as possible, even if the code counts as a “bad solution”. However, if a clean and simple code is possible within the first few tries, then it should be applied immediately, too. The main objective here is to obtain the green bar for the unit tests.
REFACTOR. Although this phase is often skipped, it is quite crucial because it eliminates code duplication and makes it possible to make changes in the architecture, presentation, and more. The refactoring involves both the unit test code and the production code.
The TDD cycle is short and is repeated until all unit tests that cover functionalities have been successfully completed:
Behavior Driven Development
Behavior 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 are
Tests are written in plain descriptive English type grammar
Tests are explained as behavior of application and are more user-focused
Using examples to clarify requirements
What is BDD?
Behavioral Driven Development (BDD) is a software development approach that has evolved from TDD (Test Driven Development). It differs by being written in a shared language, which improves communication between tech and non-tech teams and stakeholders. In both development approaches, tests are written ahead of the code, but in BDD, tests are more user-focused and based on the system’s behavior.
Choosing BDD
TDD works satisfactorily, as long as the business owner is familiar with the unit test framework being used and their technical skills are strong enough, which is not always the case. In these circumstances, BDD has the advantage because the test cases can be written in a common language used by the stakeholders such as, for example, English. This access to clearer communication is probably the biggest advantage to using BDD, making it possible for collaboration between the technical and non-technical teams to run with improved efficiency.
Characteristics of BDD
As described above, the advantage to BDD test cases being written in a common language is that details of how the application behaves can be easily understood by all. For example, test cases can be written using real-time examples of the actual requirements, to explain the behavior of the system.
Essentials to have in place before implementing BDD
Requirements should be converted into user stories that can define concrete examples.
Each example should be a valid user scenario, rather than a mere test case.
An understanding of the ‘role-feature-reason’ matrix and the ‘given-when-then’ formula.
An awareness of the need to write ‘the specification of the behavior of a class’ rather than ‘the unit test of a class’.
Behavior Driven Development Tools
There are several open-source and paid tools available for BDD framework. Here are some of the common examples below.
1) Cucumber Studio
2) Cucumber
3) JBehave
4) SpecFlow
5) Jdave
6) Instinct
7) Specs
What is Gherkin Language?
Gherkin is a business readable language which helps you to describe business behavior without going into details of implementation. It is a domain specific language for defining tests in Cucumber format for specifications. It uses plain language to describe use cases and allows users to remove logic details from behavior tests.
This script serves two primary purposes:
Documents user scenarios
Writing an automated test (BDD)
Writing Gherkin Test:
There are some keywords used in Gherkin to define complete tests including precondition, test description, expected outcome etc. Here are some of the common keywords used in gherkin language:
1. Feature
2. Scenario outline
3. Given, When, Then, And, (Steps)
4. Background
5. Scenario
6. Rule
7. Example
Each keyword has its own meaning used in writing a great Gherkin test. Those Keywords are explained below to have an understanding of each one of them.
Feature
The feature is a description of what the application is supposed to do. Feature keyword is also used to group multiple scenarios together. Feature keyword is found at the start of a feature file.
Descriptions
When required, free-form descriptions could be written underneath the given keywords, as long as all the lines are being written without any keyword.
Rule
The purpose of the rule keyword is to represent one business rule that needs to be incorporated. This keyword provides additional context for a feature. These “rules” can have one or more scenarios that can belong to the business rule and may have a background section as well.
1. Given:
Given step is used to describe the initial information of the system. Usually, it is used to describe the prerequisites before a test case execution can start.
Syntax:
Given - a test step that defines the 'context
Given I am on "/."
2. When
‘When’ is used to describe an event and an action. This can be a person or user interacting with the system. It is highly recommended that you have a single "When" step for one Scenario. If multiple "When" are needed, then it is advised to split that kind of scenario into multiple scenarios.
Syntax:
When
A When - a test step that defines the 'action' performed
When I perform "Sign In."
3. Then
"Then" keyword is used to describe an expected result or an outcome.The result of this step should be an observable output that is something like a report, message or user interface and not an internal behavior of the system like a record inside a database.
Then
Then - test step that defines the 'outcome.'
Then I should see "Welcome Lakki."
4. And, But
When we have multiple steps ,for example we have two conditions that should be valid as a prerequisite then after ‘Given’ the two steps can be separated by an ‘And’. Similarly, for ‘But’. These can be used with ‘Given’,’ When’ or ‘Then’ as needed. Using these keywords helps in keeping the documentation more organized and increases readability by making it more structured.
A But - additional test step which defines the 'action' 'outcome.'
But I should see "Welcome Michael"
And - additional test step that defines the 'action' performed
And I write "Email Address" with "Michael@gmail.com"
Given, When, Then, and, but are test steps. You can use them interchangeably. The interpreter doesn't display any error. However, they will surely not make any 'sense' when read.
Background
The same ‘Given’ steps in all of the scenarios in the feature are being repeated then those steps are not essential to describe the scenarios. They are just the event details. We have an option to move such ‘Given’ steps to the background by grouping them all under a Background section.We can only have a single set of Background steps for one feature. If you want different Background steps for each scenario, you need to split them into different feature files.
Scenario Outline
The keyword Scenario Outline is used to execute the same scenario multiple times with different sets of values.
Typical Gherkin steps look like:
Gherkin Scripts: connects the human concept of cause and effect to the software concept of input/process/output.
Gherkin Syntax:
Feature: Title of the Scenario
Given [Preconditions or Initial Context]
When [Event or Trigger]
Then [Expected output]
Gherkin Examples
Example 1:
Feature: Login functionality of social networking site Facebook
Given: I am a Facebook user
When: I enter username as username
And I enter the password as the password
Then I should be redirected to the home page of Facebook
The scenario mentioned above is of a feature called user login.
All the words written in bold are Gherkin keywords.
Gherkin will analyze each step written in the step definition file. Therefore, the steps are given in the feature file and the step definition file should match.
Example 2:
Scenario : Add product to the cart
Given the user is in the product page that he want to buy
When the user clicks "Add to cart"
Then the item should be added to the cart
Example 2
Scenario : Deleting items from the cart
Given the user have added some items in the cart
When the user clicks delete the item in the shopping cart
Then the item is deleted and cannot be seen in the cart again
Advantages of Gherkin
Gherkin is simple enough for non-programmers to understand.
Programmers can use it as a very solid base to start their tests.
It makes User Stories easier to digest.
Gherkin script can easily be understood by business executives and developers.
Disadvantages of Gherkin
It requires a high level of business engagement and collaborations
May not work well in all scenarios
Poorly written tests can easily increase test-maintenance cost
** Source of Pictures: www.google.com