DEV Community

Willian Ferreira Moya
Willian Ferreira Moya

Posted on

How to find bugs before sending it to production using boundary testing technique

Introduction

When you think of efficient testing you should consider boundary testing! This technique is crucial to help you find bugs faster even before they happen in production.

Doing this tactic you can discover what data to use to test your code efficiently! So you don’t have to spend your Friday nights fixing bugs in production. So let’s get started and explore this technique.

What is boundary testing?

Boundary testing is a black-box technique that helps to find errors at the extreme ends of the code. Being that the areas that is more likely to cause problems in your code. Developers can easily make incorrect handling limits that can cause problems like this.

It can reduce the number of tests since you are testing the more relevant parts of a range of inputs.

It's important to test this set of values:

  • test the minimum,
  • the minimum minus one
  • the minimum plus one,
  • a normal value,
  • the maximun minus one,
  • the maximum,
  • and the maximum pluns one.

And why it’s important?

Boundary tests are important because they help to find errors. Values in the boundaries can often be a source of problems in applications.

This technique can make your testing more efficient. Picking the values that are most likely to cause an issue in your code. So you have to test with less data to detect bugs in the early stage.

It can help you have more coverage in your code testing valid and invalid limits for a specific range.

Boundary testing is vital to ensure that the software will work properly.

How to do boundary tests

Let’s see in practice how you can test your scenarios by following the rules of the boundary tests.

For example, you are testing a method that should verify the password length.

The acceptance criteria must be:

  • The password should have a length of 8 or higher.
  • Should not be bigger than 20.
  • Both values at the boundaries are valid (8 and 20 characters are a valid password size)

The developer following the specification implemented this code:

public static boolean validatePassword(String password) {
    if (password == null || password.length() <= 8 || password.length() > 20) {
        return false;
    }
    return true;
}

Enter fullscreen mode Exit fullscreen mode

Looking at the acceptance criteria. We start using boundary testing looking at the partitions of the code where you can explore to find bugs.

In the code, we see that the conditions on the if statement are the most susceptible to present bugs. If they weren't implemented correctly. Let’s take a look at the partitions and see what we should be testing:

The partitions of the example code will be:

  • password == null
    • For this partition, a null and a non-null string would be enough
  • password.length() ≤ 8
    • For this partition:
      • test a password that is 7 characters long.
      • test a password that has a length that is exactly 8 characters.
      • and a test that has a length of 9 characters.
  • password.length() > 20:
    • For this partition:
      • test a password that is 19 characters long.
      • test a password that has a length that is exactly 20 characters.
      • and another that has 21 characters long.
@Test
void testValidPassword() {
    //partitions
    // password == null
    String password = null;
    // password <= 8 or password > 20

    //business rule: password must be valid between 8 and 20
    //boundaries: null -> invalid (false)
    assertFalse(PasswordValidator.validatePassword(password));
    // lenght:
    //  7 - invalid (false)
    String length7Password = "aaabbbc";
    assertFalse(PasswordValidator.validatePassword(length7Password));
    //  8 - valid (true)
    String length8Password = "aaaabbbb";
    assertTrue(PasswordValidator.validatePassword(length8Password));
    //  9 - valid (true)
    String length9Password = "aaaabbbbc";
    assertTrue(PasswordValidator.validatePassword(length9Password));
    // 19 - valid (true)
    String length19Password = "aaaaabbbbbcccccdddd";
    assertTrue(PasswordValidator.validatePassword(length19Password));
    // 20 - valid (true)
    String length20Password = "aaaaabbbbbcccccddddd";
    assertTrue(PasswordValidator.validatePassword(length20Password));
    // 21 - invalid (false)
    String length21Password = "aaaaabbbbbcccccddddde";
    assertFalse(PasswordValidator.validatePassword(length21Password));

}

Enter fullscreen mode Exit fullscreen mode

The result of the tests are:

!https://prod-files-secure.s3.us-west-2.amazonaws.com/ada74e9d-9e34-4aae-aab5-35c1701afa78/e304f428-7714-4a80-b545-446b333d18d3/Untitled.png

As you can see the developer made a mistake. That lies in the boundary parts of the code. The method must allow a password that has exactly 8 characters, but the code does not accept that. By doing the boundary testing technique you found a bug in the code. Now you can go and fix then before sending it to production!

Fixing the example code should be simple, just replacing the ≤ 8 to < 8, like this:

public static boolean validatePassword(String password) {
    if (password == null || password.length() < 8 || password.length() > 20) {
        return false;
    }
    return true;
}

Enter fullscreen mode Exit fullscreen mode

Now if we run the test again, we make sure that no bug is going to pass:

!https://prod-files-secure.s3.us-west-2.amazonaws.com/ada74e9d-9e34-4aae-aab5-35c1701afa78/f5c3b5e2-3326-4be7-8807-5d6819744cdb/Untitled.png

If the code was already running in production you can fix it. After that, add boundary tests to the broken code to make sure that the code will not break again.

Conclusion:

In summary, boundary tests can make your life easier when testing! By making it easy to select what data to test, and what to focus on the code partitions that have bugs.

Doing that can prevent the bug from going to production. Because you can detect an issue in the implementation of the feature!

So go do this technique right now in your code! It can save you lots of time finding bugs!

This post is gonna be part of a series of posts about efficient testing. If you like it, make sure to follow me here and get to know when the other parts come out! See you soon!

Top comments (0)