System tests

At some point, your classes, business rules, persistence layers, and so on are combined to form, for example, a web application. Let’s think about how a web application traditionally works. Users visit a web page (that is, their browser makes a request to the server, and the server processes the request and returns a response that the browser shows) and interact with the elements on the page. These interactions often trigger other requests and responses. Considering a pet clinic application: a user goes to the web page that lists all the scheduled appointments for today, clicks the New Appointment button, fills out the name of their pet and its owner, and selects an available time slot. The web page then takes the user back to the Appointments page, which now shows the newly added appointment.

If this pet clinic web application was developed using test-driven approaches and everything we discussed the developer already wrote (systematic) unit tests for each unit in the software. For example, the Appointment class already has unit tests of its own.

In this section, we discuss what to test in a web application and what tools we can use to automatically open the browser and interact with the web page. We also discuss some best practices for writing system tests.

NOTE Although I use a web application as an example of how to write a system test, the ideas in this section apply to any other type of software system.