What is Test Driven Development? TDD vs. BDD vs. SDD

Artem Golubev

TDD is a software development practice driven by the testing process, combining coding and writing unit tests iteratively. TDD focuses on developing smaller pieces of functionality in isolation. The primary motive is to create a failing test first, then write just enough code to ensure the test passes. That way, developers can be sure if their code works or not.

An example could include asserting the results for a specific method in your application.

TDD vs. BDD (Behavior-Driven Development) – What’s the Difference?

TDD and BDD might seem very similar as both strategies include writing tests before code to ensure a bug-free application. However, BDD tests an application’s behavior from an end-user perspective. BDD is more concerned about the result of the higher-level scenario rather than a specific method.

TDD can be done by a solo developer whereas, in BDD, various stakeholders, who might include product managers, testers, and developers, collaborate before coming up with a test scenario.

TDD process – Implementation

1. Unit test creation

   – Developers create precise unit tests to validate a specific user functionality. As they are writing tests based on the assumption of how the code will work, they are bound to fail at the start.

2. Code correction

   – Once the test fails, developers need to make changes to the code to ensure it runs smoothly on the next run.

3. Code Refactoring

   – Once the test runs successfully, look for possible code optimizations and script duplications to enhance the performance.

Types of TDD – ATDD vs. DTDD

There are mainly two types of test-driven development – one being ATDD (Acceptance TDD) and the other being DTDD (Developer TDD).

1. Acceptance TDD (ATDD)

   : ATDD is very similar to BDD (Behavior-driven development). The difference between ATDD and BDD is that ATDD mainly focuses on accuracy of requirements, vs. BDD primarily focuses on user behavior.

2. Developer TDD (DTDD)

   : DTDD is simply the basic TDD approach where the developer writes the unit test before writing enough production code to fulfill those tests.

TDD Example Implementation

For test-driven development example, we will write a password acceptance test as follows:

The password should contain at least one digit (0-9).

// PasswordAssertion class
public boolean validatePass(String password) {
  int digit = 0;
  for(int index = 0; index < password.length(); index++ ){
    char element = password.charAt( index ); // fetch character
    if( Character.isDigit(element) ){ // If element is a digit
      digit++;
    }
  }
  if( digit >= 1 )
    return true;
  else
    return false;
}

// TestPassword class
1.PasswordAssertion validator = new PasswordAssertion();
2.Assert.assertEquals(true, validator.validatePass("MyPassw0rd123"));

As the above password fulfills the requirement, the unit test created would pass. Hence, no code changes are required.

Once the test passes, developers can look for possible refactoring like removing the instance creation line for PasswordAssertion and directly calling the method by className.

// TestPassword class
Assert.assertEquals(true, PasswordAssertion.validatePass("MyPassw0rd123"));

When you run the above code, it will

fail

as you cannot call a non-static method without a reference. Now, once the test fails, make minimal changes in the code.

Code Correction – make the member method static inside PasswordAssertion class.

public boolean static validatePass(String password) {
  .............. same code as above
}

Now, run the code in

TestPassword

class, and the test will pass.

The whole lifecycle of test-driven development is where you repeat the test steps upon pass or failure.

Benefits of Test-Driven Development

1. Higher test coverage

   – Test code coverage is pretty high in test-driven developments as it focuses on writing tests for each basic user functionality from the start, contributing to the overall quality of the product under test.

2. Lower defect density

   – With TDD, tests are created for each defect or bug in the product, so there is a high probability that bugs would not reoccur as the tests are running for each bug fix.

3. Better productivity

   – With TDD, developers have the power to maintain a flexible code before the product goes into all other kinds of testing – Smoke and Regression. Moreover, the testing team would have more flexibility in time to incorporate regression testing.

Common Pitfalls While Doing Test Driven Development

At an individual level, developers may write too many tests at once, even for overly trivial code, or may write coarse-grained tests that are difficult to maintain.

Partial adoption of TDD by some developers in the team and poor maintenance might lead to long running times for test suites.

Various Unit Testing Tools Supporting TDD

1. PyTest

   – PyTest is a Python unit testing framework.

2. JUnit or TestNG

   – Java unit testing frameworks.

3. RSpec

   – RSpec is for Ruby projects.

When Not to Use TDD in the Organization

Irrespective of the benefits provided, it is advisable not to use TDD by everyone in every situation.

For example, it is not recommendable to develop a GUI in a test-driven way. BDD would be better, in that case, considering the system’s behavior.

• When Test code requires maintenance and production code

  – As it grows linearly with the production code, it becomes hard to maintain the unit tests with only a minor change to the production code.

• When you want to reduce the cost of implementing a functionality

  – Implementing test-driven functionality requires more effort than the conventional way, depending upon the organizational support and the developer’s experience.

A tradeoff exists between production bugs and manual regression timing in a test-driven development. As the project grows, the time for regression testing grows, but more and more bugs will go into production if you try to freeze regression timing, making the addition of new functionality slower with the project.

What is SDD?

While TDD is an excellent approach for the development team alone, BDD is fundamentally flawed – which is why remarkably few companies have ever succeeded in using this approach. That is why, at testRigor, we created a Specification Driven Development (SDD) term. 

SDD provides tremendous benefits, drastically simplifying the whole flow and saving software teams a lot of time. In this approach, the team can write a test in plain English, which is also an executable specification. This means that once the development team is done building the feature, the test can be executed immediately without any additional modifications.

How does SDD look like?

click "Register"
generate by regex "[a-z0-9]{30}\@my_company\.com", then enter into "Email" and save as "newEmail"
enter "MyPassw0rd123" into "Password"
click "Sign Up"
check that email to saved value "newEmail" was delivered
check that page contains button "Confirm Registration"
click "Confirm Registration"
check that page contains text "Successfully confirmed"

Impressive, right? This is what testRigor is great at – streamlining the software testing process.

You’re welcome to set up a free account and try it out yourself! Or otherwise requesting a demo from our team of specialists might be the best way for you to learn how your company will benefit from employing testRigor.