Feedback is an element of utter importance in the entire software development life cycle. It exhibits the progress rate of a project and ascertain developers that they are moving in the right direction to deliver what is expected by the stakeholders. In a conventional approach for software development, testing is usually followed by code designing. While this model has got assured advantages, it has got some stumbling blocks as well. For example: Delay in project delivery due to error fixing and changes in application functionality at later stage.
So, how about doing it the other way around? Well, that’s possible with test-first development models like TDD and BDD, wherein a test is written before a production code is written for the test and refactoring.
What is the benefit of adopting these test-first development models over the traditional development methodologies? How do they combine with automated testing frameworks? Which one amongst TDD and BDD is the preferred approach for software development? Let’s find out answer to these curious queries in your head through the segment shared below.
Test-Driven Development (TDD) is an approach towards software development wherein automated test cases are written before functional code elements of the project are written. For ease and manageability, small unit tests for the project are designed. The development cycle goes like:
Add Test: A test is created, keeping an account for all the inputs, outputs, and errors that can be encountered.
Run Test: The test is then run against the a code. There is a possibility that the test will fail. Reason being, the code is not written to satisfy the test.
Write Code: Considering the specifications in the test, an improved version of the existing code is generated. This continues until the code satisfies the test conditions.
Re-factor: With time, the code base starts to grow as different set of codes combine after passing the unit tests. At this stage, it is important to improve (or refactor) the code in a number of ways. For example: Look out for class, objects, or modules name should clearly represent their purpose. Any kind of duplicacy might create hurdle in its functionality.
Repeat: The entire process is repeated for different unit tests.
Behaviour-Driven Development (BDD) is an extension to TDD, wherein the idea is testing behaviour of the application, clarifying requirements through examples, and setting communication between the stakeholders, developers, QAs, and other non-technical department. The development model focuses on:
- From Where to start the process?
- What has to be tested?
- How much to test at a time?
Understanding the Difference:
Suppose, a web application has to be developed with feature to let the users to pay their mobile bills. This process takes place in following steps:
- User login by providing Username and Password
- Enter credentials about mobile, mobile operator
- Make Payments by providing card details
When Test-Driven Development approach is followed, the test lay emphasis on each unit of development. For example: When a user comes at the login page, he should be asked to enter credentials like Username/Password. Once login is successful, mobile number and operator details should be collected from user, and so on.
On the other hand, BDD development points up on behaviour of the units. For example: How the login page should be, checking the username/password entry, validating login only when both the fields are entered and so on.
- The major advantage of BDD over TDD is, the specifications defined in test never changes, it’s the implementation has to be changed in order to change behaviour of the application.
- The specs and requirements in the test are written in a language that can be easily understood by the domain level experts like users, stakeholders, project managers, QAs etc.
How to get Started with TDD/BDD Testing?
Now the point is, how these tests are written for the developers and executed. The user stories, requirements, and specs are defined in Gherkin syntax, which is used to define tests. A living documentation of the project to be developed is created using domain language that technical and non-technical people understand.
For example, BDD test specs for .NET can be defined by non-programmers and translated into automated tests by developers with tools like Specflow. Once the test specifications are designed, bind them with the software application code. As you start the code, check out if all the tests are passed and there you are with a development cycle that render results as expected.
