Testing is an essential part of programming: making sure your code is written properly and does what it was designed to do. It can be a tedious process, which is why automated testing is one of the most important tools in a programmer’s toolbox. But what kind of automated testing should you perform? And how do you go about it? Here are a few important terms you should know when it comes to testing your code.
As its name implies, unit testing divides your code up into its individual units and tests them each separately. By breaking it down in this way, you can easily determine if each part does what it was designed to do. If there is an error, you can see immediately where the error is and fix it.
Think of it as a string of Christmas tree lights. Years ago, strings of lights were designed all on a single circuit. If one bulb was bad, the circuit was broken, and none of the lights on the string would light up. In order to fix it, you had to go through each light individually and find the bad one. But now, each light operates separately, so that all you need to do is look at the string, see which one isn’t lit, and replace it. That’s what unit testing is like, as opposed to testing the entire project as a whole
Of course, often, different units of your code are dependent on one another to work, which can make testing them individually difficult. But in isolating the units, you can add fake dependencies, wherein you control the variables yourself. This lets you test under a variety of different conditions and get more thorough results.
TDD refers to the process of writing and repeating tests on your software over a short amount of time in order to optimize it. It allows you to test more thoroughly while reducing the number of bugs in your tests.
The way it works may seem counter-intuitive at first. You begin by writing a test that’s designed to fail. That way, if your software passes the test instead, you know there’s a bug that needs to be fixed. Once your test has failed, write the minimum amount of code necessary to get it to pass, and run the test again. Then repeat this for each of your units.
It can be a tricky process, but if you can master it, TDD gives you great code coverage, because there are so many tests you’re performing. It also allows you to add new features simply and easily.
Many unit tests are based on how the unit is implemented. The problem with this is, if you want to implement the unit differently, you need a different test for it. But BDD instead focuses on how the unit is meant to behave. If it does what it’s supposed to, it passes the test. If not, fix it and test again.
Unit testing, TDD, and BDD are all great practices for software testing, each providing different benefits to your project. For best results, your ideal testing automation process will implement all of them.
What sort of tests do you perform on your software to ensure that it functions the way it was designed to?
Author: Chris Fontes