Why regression tests are so important
By Alexandra Martinez
This post will give you an overview of regression tests and why it’s important to implement sets of tests for all of your development projects.
I’ll be using examples based on APIs (application programming interface), so if you don’t know what they are, please feel free to stop and read my previous blog posts: Introduction to APIs – Part 1 and Part 2. For the sake of this post and the examples I’m going to use, an API will return data that a human can visually understand, and that’s clearer for people who aren’t software developers.
What is regression testing?
If you search regression testing, you’ll find this: “Regression testing is re-running functional and non-functional tests to ensure that previously developed and tested software still perform after a change. If not, that would be called a regression.”
If you ask me what regression testing is, I’d answer something like, “It’s a type of software testing to make sure a new change to the code did not break existing functionality.”
But what does it mean? Let me give you an example!
Let’s say you have an API that returns the information of an employee. As of today, you only return the First Name, Last Name, and Date Of Birth of that employee:
(Yes, I’m that old!)
Then, you add your first feature to now return a new field called “Age” that will contain, you guessed it, the age of the employee based on the Date Of Birth. Here’s what this new feature would look like:
Now let’s pause, because we don’t want to show the age to just any person. What if I asked you to create a second field called “AuthorizedUser” that will return a “yes” or “no” value to make sure only certain users have access to employees’ age. If the field’s value is “yes”, it will go ahead and show the age, but if the value is “no”, it won’t show the age of the employee. This second feature would now look like this:
By the way, have you noticed that the “DateOfBirth” field sounds a bit weird? I say we have to change it to “BirthDate” instead. Let’s work on our third feature for this change. It’ll look something like this:
Great, we’re all done! We finished all our code additions and changes, but wait! We didn’t check what would happen if the “AuthorizedUser” field was “yes”. Let’s see what happens:
Uh oh, it seems that we forgot to update the “Age” field since it was based on the field called “DateOfBirth” which we decided to change to “BirthDate”. This wouldn’t have happened if we had regression tests in place.
So what would’ve happened if we had regression testing?
If we had our set of tests ready for regression testing, when we implemented the second feature (feature2) of the “AuthorizedUser” field, we would’ve created two different tests: the first one to check the fields in response when “AuthorizedUser” was “yes”:
And the second test to check the fields in response when “AuthorizedUser” was “no”:
We tested it when we implemented it, and it worked just fine, but when we worked on the third feature (feature3) to change the field name from “DateOfBirth” to “BirthDate”, we completely forgot that the”Age” field was being calculated using the “DateOfBirth” field. Since our API didn’t find that field anywhere, it returned just a zero.
If we have regression tests and we run them before finishing adding features, we’ll make sure we’re not breaking any of the previous functionality, and update the previous code to the new code to keep it working as it should.
Now that we noticed that the “Age” field has to be updated to use the updated “BirthDate” field, we can make that change, but not as a feature, as it is now a bug fix. And we can see that it now returns the correct data:
So why is this a bug fix and not a new feature? Because the functionality to return the correct age was already in place, which is not new functionality. The feature3 addition was to change the field’s name, and by doing so, we should be aware that the “Age” field is going to be affected by this, meaning it has to be updated as part of feature3. Since we didn’t do that, we lowered our quality as software developers and introduced a bug to the API.
Now this example was very simple. When programming APIs, it’s expected to have thousands of lines of data. These examples didn’t have more than 7 lines. It’s the software development team’s responsibility to thoroughly test their changes before finishing a development (both new features and bug fixes) in order to not avoid bugs in the code. This is why regression testing is incredibly important. Would you want to manually review at least 5,000+ lines of data to be sure your changes aren’t breaking current functionality? I know I don’t.
I hope this post was helpful and I hope that you want to learn more about regression testing. If so, check out my other blog on how regression testing can save you time AND money!
About the author
Alexandra is a MuleSoft Developer where she’s responsible for leading and mentoring teams, always ensuring the best quality for project deliveries. Made in Mexico, she enjoys learning new technologies and is always looking for new challenges. She loves statistics because she’s bad at them, so they keep her alive (an eternal challenge). Her natural habitat, however, involves watching Netflix and playing video games.
