Unit testing is largely hated and ignored by developers. Many deem it a waste of time, arguing that writing code that tests code simply gets in the way of finishing projects. After all, if it works, it works right? Why write tests at the ‘unit’ level if the functionality will change anyways? Sure things like selenium and end to end testing provide ways to test your project, but why go beyond this and test individual units of code?
Such complaints are common for the inexperienced. After developing software for 5+ years, it’s clear that unit testing has a very important place in the world of test driven development (TDD). Below are the top reasons why every developer needs to start with unit testing for ANY coding endeavor.
Anyone whose read up on software design principles knows the concept of ‘separation of concerns’. Your code should be separated out as much as possible so that each function you write solves/addresses a single piece of functionality. This makes your code more reusable as independent parts operate without needing to know context, etc.
This concept sounds pretty straight forward but things can quickly get messy when developers rush to make something work. For example, say you write a function that returns JSON from some REST url. You may write a wrapper for calling the URL and storing the results in a variable for later use. You may then later realize you need to parse the JSON response before storing it in a variable. Now your function is doing two things, returning the JSON response AND parsing it.
What’s the issue here? You can now only use this function elsewhere if you are parsing the data the exact same way. What if you want to hit another REST endpoint the same way but do something different with the response? You now have to write the same code twice to retrieve the JSON and parse it differently.
How does unit testing address this? If you start with unit testing, then you can more accurately anticipate and separate out your code. Following our example, you would write a unit test for bringing back the JSON response and then separately write a test for parsing the response. This would give you the wherewithal to separate out this functionality. Not only will this make the unit testing easier, it will also more efficiently separate responsibilities.
Unit testing provides a more granular check on your code. When something isn’t working properly, your unit tests will more specifically indicate what’s causing your code to break. While a functional test may tell you that a button doesn’t trigger the right event, you still don’t know what’s causing that action to fail. With unit tests, you can more easily drill down to the specific piece of code that’s causing the bigger issue.
This works especially well with continuous integration. As your code base grows and more developers contribute, each developer can run unit tests locally before committing their work to a centralized repo. This ensures that any addition isn’t breaking existing functionality, helping to avoid major headaches and bigger issues down the line.
Going off the collaboration benefits, unit testing makes refactoring and enhancing your code less of a headache. While you may rewrite functions with fewer lines of code, the underlying goal or return value of those functions shouldn’t change. Unit tests provide a double check that what you just changed or refactored isn’t jeopardizing or changing the underlying functionality of the code.
If you write unit tests before the actual code, then you effectively provide a blue print of what you want to happen. This follows the behavioral driven development (BDD) philosophy as unit tests declare a set of rules that your code will address. If a developer looks at your test suite, they will see the desired outcome/functionality for every function in your code base.
Unit testing keeps code organized. It influences good design and minimizes the headaches with collaboration and refactoring. While it may seem tedious, you will greatly benefit from unit testing as your code base grows. Starting with unit tests will ultimately save development time and cost. Don’t be lazy, write those unit tests!