There are many practices that go into creating great software, but for me, one of the most efficient and effective ways to do that is through automated unit testing. It might sound difficult, but once I explain, you will understand how this common, but often overlooked, coding feature is worth the extra time.
What is Automated Unit Testing?
In order to define automated unit testing, we must first define the concept of a unit test. A unit test, in the context of software development, is code written by a programmer to validate a unit of code which is needed to meet business objectives. As a very simple example, let’s say I have a requirement in my software that the user needs to be able to input two numbers, A and B, and receive the sum, C, as an output. As a programmer, I might decide to create a function called ‘GetSum’ to accomplish this. After implementing the ‘GetSum’ function, I would then proceed to create a unit test for the function. We’ll call this unit test, ‘Test_GetSum’, and it would look somewhat like this pseudo-code:
variable A = 3
variable B = 4
variable C = GetSum(A, B)
if C is not equal to 7
throw an error!
This test simply takes real world test values, 3 and 4, and passes them into our GetSum function. Finally, the test takes the output of the function, and compares it with the value 7. If they aren’t equal, then the software has a problem, and an error is thrown, alerting developers and testers of the issue.
All of that being said, automated unit testing is merely the technique of building and executing all of the unit tests for a piece of software in an automated fashion. Whether the unit tests run every night, or after every check-in of code, depends on a variety of factors including team size, hardware limitations, and deployment frequency of the software being validated.
The Challenge of Writing Quality Unit Tests
Developing the habit of writing quality unit tests is tough and sometimes tedious. As a developer, it’s easy to fall into the cycle of writing a piece of code, testing it a few times (without writing the unit test for it), and then moving on. This can happen for a variety of reasons, whether it be unforeseen development obstacles or scope-creep (as mentioned by Ryan Bliss in his article, 7 Reasons for Project Failure).
Even a slight setback can cause the development of unit-tests to be put on the back-burner in favor of adhering to the software’s delivery schedule. However, given the ever evolving nature of the supply chain industry, investing in higher quality unit tests will only pay off in the long run for both the software vendor and the customer.
Reaping the Rewards
Only by investing in the development of unit tests can one reap the rewards. Here are just a few reasons why a heavy investment in unit testing is worth it:
1. Increased Confidence
Developing software can be stressful, for both the vendor and the customer. There may be hundreds to thousands of requirements for a given piece of software which equates to hundreds of thousands of lines of source code. Then, when you add in the fact that many of the requirements depend on other requirements, or even third-party vendors, the complexity increases further.
As time goes on, and the code base grows, confidence in software that lacks unit tests naturally dwindles. By knowing, without a doubt, that various requirements for a piece of software are currently being fulfilled, and that, when a requirement breaks, everyone will be well informed of the issue, everybody involved can sleep easier at night. This increased confidence is then transferred to the customer through effective delivery of error-free software.
2. Quality Assurance Throughput
Quality assurance plays an important role for all software vendors. It is the last line of defense before software lands in the customer’s lap and includes validating customer requirements both manually and using various testing tools. That’s quite a hefty burden, given that the quality assurance team usually doesn’t participate in the actual programming of the software itself.
Occasionally, a developer will have to make a code change deep within the code base, a change that every customer requirement depends on. Without any unit tests in place, this essentially means the quality assurance department will have to regression test all of the customer requirements before the change may be deployed to the customer. With unit tests, the scope of required re-testing shrinks and the customer can receive fixes and feature additions in a timelier manner.
3. Improvements and Feature Additions
Just as the supply chain industry is evolving, so does the technology behind the software. Every day, new and exciting technologies emerge that could bring extra value to our customers. However, without providing good code/requirement coverage using unit tests, upgrading these customers to these new technologies would be an incredibly costly feat.
In addition to new development technologies, many customers continually come up with innovate new ways to improve their process. These improvements usually require feature changes or additions to the software, which comes with less cost and risk when the software vendor appropriately implements unit tests into their development life-cycle.
I’ve already seen the benefits of unit testing in my first year at Bastian Software Solutions. One of our goals (and one that I assume most software vendor’s have) going forward is to keep improving our development process so that we can provide higher quality software at a lower cost, and continually improving our automated unit testing procedures is one of the many essential keys to furthering that goal.