As I mentioned in my previous blog What Types of Software Testing Can and Should be Automated?, Unit Tests comprise the largest portion of your automation library. Using Test Driven Development, developers create Unit Tests as they develop their code so that each Unit Test tests a tiny piece of software code usually before the code is written. Initially the Unit Test fails and once the Unit Test passes, that code is considered complete. As a result, Unit Testing provides numerous benefits including finding software bugs early, facilitating change, simplifying integration, and providing a source of documentation.
Benefits of Unit Testing
Find Software Bugs Early
By adding Unit Tests to the software build process, or as part of the Continuous Integration process, as the code base grows larger, these tests run automagically. When a failure occurs, either the failure is caused by a bug in the code or a problem with the actual Unit Test. Either way, pinpointing the location of failure is easily traced. Since Unit Test failures alert the Development Team before the code is pushed to Testers or Clients, it is still early in the development cycle making the fix less costly than if found later in the development cycle (for more on this check out For Great Quality, Bring Your Software Testers in Early by LaTonya Pearson).
Continuous Integration (CI) is the merging of all the developers’ working code into a shared repository several times a day. CI was originally intended as the process of running all Unit Tests in the developer’s local code branch to verify that all tests pass before committing the code to the main repository branch.
Unit Tests ensure that the code still functions properly as the code base changes with code refactoring and as the code base grows. Code refactoring is the process of restructuring existing software code without changing its original behavior. Advantages include streamlined code that is both more readable and less complex.
Unit Testing verifies the accuracy of the each Unit. Afterward, the Units are integrated into an application. By testing parts of the application via Unit Testing, later testing of the application during the Integration process is easier due to the verification of the individual Units.
Although rarely the sole source of documentation, Unit Tests provide a living documentation of an application. Developers wanting to learn what functionality is provided by a particular unit can refer to the Unit Tests to gain an understanding of the unit’s Application Programming Interface (API). The API specifies a component in terms of their inputs, outputs, and underlying types.
The Limitations of Unit Testing
Like I stated in Automation Testing: Problems, Myths, and Misconceptions to Consider, manual testing can never be fully replaced by automation. The same is true for the Unit Test portion of your test automation library because it’s nearly impossible to evaluate every single execution path in all but the most basic applications. As such, use of a version control system is critical so that if a later version fails, the version control system can display the list of software code changes since the working version. A version control system also provides an easy to way to revert back to previous versions of your code.
Here at Segue, our developers create Unit Tests on our larger, longer-term projects where we can better reap the benefits of the investment in time. Ideally these Unit Tests are included in the build process so that broken code does not continue down the pipeline to the Testers or Clients. If Developers run their tests before checking their code into the main repository, then you get a warning of faulty code even earlier.