Chapter 24: Software Unit Testing Frameworks

 Download CD Content

In This Chapter

• Unit Testing versus System Testing

• Brew Your Own Frameworks

• Testing with the C Unit Test Framework

• Testing with the Embedded Unit Test Framework

• Testing with expect

Introduction

Writing software is difficult, even when building on an outstanding operating system such as GNU/Linux. The complexity of software grows as the sizes of the systems that we develop grow. But even when developing smaller systems, problems can still find there way in. This is where testing comes in. Even if we develop software that doesn t work the first time, performing tests on the software can identify the shortcomings, allowing us to fix them.

If our tests are repeatable, we can easily retest our software once we ve made changes to it ( otherwise known as regressing ). This makes it much easier to update our software, since we know it s easy to verify that we haven t broken anything when we re done. If we do find something that s broken but wasn t tested before, we simply update the regression test to check it in the future.

In this chapter, we ll look at a number of available open source unit testing frameworks and how they can be used to improve the quality of our software.

Unit Testing

First, let s address what is meant by unit testing. For this discussion, let s divide testing into two unique categories. The first is end-to-end (or system) tests, which test specific user -level features of the software (see Figure 24.1).

Figure 24.1:    System testing (or end-to-end) perspective.

We can also think about this as testing based upon the requirements of the software. In this category, we typically don t consider how the software is constructed (black-box testing) but instead simply test for what the system should do. As illustrated in Figure 24.2, the components of our system can be further broken down into smaller modules called units .

Unit testing assumes more knowledge and insight into the software to be tested. Unit tests address units of a software system and therefore don t typically address system requirements but instead internal behavior of the system. Let s say that our software system included a queue unit that was to be used for internal task communication. We could separate this queue unit from the rest of the system and test it in isolation with a number of different tests. This is a unit test, since we re addressing a unit of the system (see Figure 24.3). We also commonly consider how the unit was constructed and therefore test with this knowledge (white-box testing).

Figure 24.2:    System components are made up of units.

This permits us to ensure that we ve tested all of the elements of the unit (recall the use of the GNU gcov utility in Chapter 7, Coverage Testing with GNU gcov ).

Figure 24.3:    Unit testing perspective of an individual software unit.

Therefore, a unit test simply invokes the unit s APIs and verifies that a given stimulus produces an expected result.