_edited_edited.png)
Test Driven Development (TDD)
TDD is a software development process relying on software requirements being converted to test cases before software is fully developed and tracking all software development by repeatedly testing the software against all test cases. This is opposed to software being developed first and test cases created later. The main intention of this technique is to modify or write a fresh code only when the test fails. Hence it results in lesser duplication of test scripts. This technique is largely popular in agile development ecosystems. In a TDD approach, automated test scripts are written before functional pieces of code.
Test-driven development cycle
1. Add a test: Based on the requirements specified in the documents, a developer writes an automated test case.
2. Run all tests: These tests are executed, and in some cases (The new test should fail for expected reasons.), they fail as they are developed before the development of an actual feature.
3. Write the simplest code that passes the new test: All tests should now pass.
4.Refactor as needed, using tests after each refactor to ensure that functionality is preserved: Re-factoring refers to the process of modifying the code without changing its main functionality or behavior.
Benefits of TDD
➔ Helps reduce the amount of time required for rework.
➔ Helps explore bugs or errors very quickly.
➔ Help get faster feedback.
➔ Encourages the development of cleaner and better designs.
➔ Enhances the productivity of the programmer.
➔ Allows any team member to start working on the code in the absence of a specific team member. This encourages knowledge sharing and collaboration.
➔ Gives the programmer confidence to change the large architecture of an application easily.
➔ Results in the creation of extensive code that is flexible and easy to maintain.
Behavioral-Driven Development (BDD)
Business-Driven Development (BDD) is a testing approach derived from the Test-Driven Development (TDD) methodology. In BDD, tests are mainly based on systems behavior. This approach defines various ways to develop a feature based on its behavior. It is an agile software development process that encourages collaboration among developers, QA, and non-technical or business participants in a software project. Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.
BDD focuses on:
➔ Where to start in the process?
➔ What to test and what not to test?
➔ How much to test in one go?
➔ How to understand why a test fails?
Key benefits of Behavioral-Driven Development approach:
➔ Helps reach a wider audience by the usage of non-technical language.
➔ Focuses on how the system should behave from the customer’s and the developer’s perspective.
➔ BDD is a cost-effective technique.
➔ Reduces efforts needed to verify any post-deployment defects.
How does BDD help in SDLC?
Debugging the errors in the latter stages of the development life cycle often proves to be very expensive. In the majority of the cases, ambiguity in understanding the requirements is the root cause behind this. One needs to ensure that all the development efforts remain aligned towards fulfilling pre-determined requirements. BDD allows developers to do the above by:
➔ Allowing the requirements to be defined in a standard approach using simple English.
➔ Providing several ways to illustrate real-world scenarios for understanding requirements.
➔ Providing a platform that enables the tech and non-tech teams to collaborate and understand the requirements.
In most cases, the Given-When-Then approach is used for writing test cases.
Given-When-Then (GWT) is a semi-structured way to write down test cases. They can either be tested manually or automated as browser tests with Selenium.
It derives its name from the three clauses used, which start with the words given, when and then.
Given describes the preconditions and initial state before the start of a test and allows for any pre-test setup that may occur.
When describes actions taken by a user during a test.
Then describes the outcome resulting from actions taken in the when clause.
Let’s take an example for better understanding:
• Given the user has entered valid login credentials
• When a user clicks on the login button
• Then display the successful validation message
As shown above, the behavior is illustrated in a very simple English language, also known as a shared language. This helps everyone in the team responsible for development to understand the feature behavior. BDD does not have any formal requirements for exactly how these user stories must be written down, but it does insist that each team using BDD come up with a simple, standardized format for writing down the user stories which includes the elements listed above.
Understanding how these methods work can help developers and other individuals involved in software development, figure out which test strategy works best to serve their purpose. Depending on the kind of project and the results it aims to achieve, the right method (or even a mix of methods) can be deployed to meet specific requirements in the most efficient ways.
References
4) https://blog.j-labs.pl/index.php?page=2017/02/Given-When-Then-pattern-in-unit-tests