The Testing Landscape

---

If you’re employed by a large organization, you may have the luxury of working with a well-staffed and trained quality assurance (QA) department who will test your code. If you’re in a small shop, you might well do most of your own testing. Either way, you should have some feel for the major types of testing that most software is subjected to, and you should appreciate that part of your job as a developer is to perform your own testing.

Types of Testing

Every developer knows that software requires testing, but that simple word “testing” encompasses quite a few activities. Here are half a dozen types of testing that you might consider for any given application:

• Unit testing Testing very small pieces of code is called unit testing. These are the units that make up an entire application. These tests focus on very small sections of the code to ensure that those small sections are doing what they are supposed to do.

• Integration testing When different developers are working on different parts of the code, it doesn’t always fit together as it should. The goal of integration testing is to ensure that your code doesn’t break someone else’s code, and vice versa. Integration testing might consist of simply running all the various unit tests to make sure the various bits of code continue to perform as designed.

• System testing When you have a separate QA group, they often focus on system testing: exercising the entire application to see if they can make it fail. System testing often consists of a mix of automated tests and ad hoc “banging on” the application to see if it can be made to fail. System testing can uncover interactions between components and bugs that the developers never even considered.

  Note

  Testing is a laborious task, and very few good tools are available to help you. You might want to take a look at Developing an Automated Software Testing Tool, by Kanglin Li and Mengqi Wu (Sybex, 2004), which teaches testing procedures and takes the reader through the steps for developing a powerful automated testing tool. All of the code for the tool is provided with the book.

• Stress testing The goal of stress testing is to push the limits of an application until it fails. This might mean using a large number of simulated users, or huge database records, or running the application on a computer with limited RAM.

• Beta testing Beta testing involves giving copies of the unfinished code to testers outside of your organization so that they can exercise the code and report on their findings. Beta testing can also be used as a marketing tool to expose large numbers of prospective customers to a new product before it is shipped.

• Acceptance testing Depending on the process you’re using, you might formally verify that an application meets each of the requirements precisely. Such formal acceptance testing can verify that software will do its job, but it tends to miss bugs caused by unexpected usage.

Testing for Developers

As a developer, you might engage in any or all of the forms of testing I’ve discussed. But unit testing and integration testing are typically the most important of these activities for developers. One typical pattern of work for developers in a team looks like this:

1. Check out the module that you’ll be working on.

2. Write the code for the next feature you’re implementing.

3. Write the unit tests to test the feature.

4. Make sure the code passes the unit tests.

5. Get the latest code for the entire application from your source code control system.

6. Make sure the whole project passes the integration tests.

7. Check in your code and unit tests.

RULE

When there are multiple developers on a project, it’s important to run the integration tests before you check in your changes.

Running the integration tests before checking in the code is the easiest way to make sure that your code doesn’t inadvertently break some other part of the application or interact poorly with another change that was checked in while you were working on your own changes.

Warning

Although developers sometimes do their own system testing, it’s definitely a better practice to have someone else do this. It is very, very difficult to give code a thorough systems test when you’re the one who wrote the code. If you had a blind spot about a potential problem when you were writing the code, you probably won’t think to test that problem later on.

---