
Web apps, meant to be used by people—in contrast to APIs—usually consist of at least two major parts: the frontend and the backend, both of which have their own challenges and need to be tested. This post is all about backend testing.
As you read this guide, you’ll learn what backend testing is, why it’s important, how it differs from other types of testing, and more.
“More than the act of testing, the act of designing tests is one of the best bug preventers known.” – Boris Beizer, Software Testing Techniques
What is backend testing?
Before covering what backend testing is, let’s explain what it isn’t. Backend testing is not necessarily another, distinct type of testing, in the same way that unit testing or integration testing are. For instance, a question such as “What is better, unit testing or backend testing?” doesn’t make sense.
What is backend testing, then? It’s an umbrella term that encompasses all types of testing that are related to the backend—that is, the non-user-facing portions of the application.
Backend testing includes testing of:
- API endpoints, including functional testing and non-functional testing (e.g., performance testing, load testing, and so on)
- Databases
- Server-side code, including unit testing and integration testing
Backend testing is crucial if you care about the quality of your applications
What happens if you don’t implement backend testing?
Backend testing is crucial if you care about the quality of your applications. Problems caused by poor or complete lack of backend testing include:
- Correctness issues: The application doesn’t do what it was supposed to.
- Data integrity issues: The application fails to store and manage its data without corruption.
- Performance problems: The application loads too slowly or crashes under heavy loads.
- Security issues: Malicious actors might expose security vulnerabilities, such as the use of compromised libraries, poor secrets management, or poor input validation.
- Error handling failures: When unexpected errors happen, the application might suddenly crash, with poor or no messaging to the user, causing user experience issues and the possibility of data corruption (see list item #2).
To sum it up: backend testing is needed because you want your applications to operate with correctness, robustness, speed, and a great user experience.
How does backend testing differ from frontend testing?
Frontend testing and backend testing are similar in the sense that they’re both umbrella terms that encompass a number of different types of testing. Types of testing that fall under frontend testing include, but aren’t limited to:
- Unit testing of components (for instance, in a framework like React)
- Frontend integration testing (exercising the UI via something like Playwright while the API calls are mocked)
- Unit testing of JavaScript code not necessarily related to the UI and the DOM (such as utility libraries or services)
Obviously, frontend testing cares a lot about the UI and the overall user experience, which means testing the look and feel of the application, its accessibility, whether the text the user sees is correct, and whether the layout elements look correct (in the right place on all devices and screen sizes, etc.).
Speaking of devices, therein lies another fundamental difference between backend and frontend testing. When it comes to the backend, all of the processing happens on a server. That’s not true for the frontend, where the processing happens on the user’s device.
So, user choices matter a lot more when it comes to frontend testing:
- Whether the user is accessing via a computer, a tablet, or a smartphone
- Their choice of browser and screen size
- Whether they use browser add-ons that may impact the application’s behavior
Backend testing types and key components
What are the key testing types and components that are part of backend testing? There’s no one-size-fits-all answer to this question, because different scenarios require different approaches.
For instance, what’s seemingly a single application could be a distributed system consisting of many APIs and microservices, employing several databases, messaging brokers, caching solutions, and more. The testing approach for such a scenario would be vastly more complicated than the one for a single MVC application written in Django and backed by a PostgreSQL database.
With that said, there are types of testing under the backend testing umbrella that are so essential and omnipresent that we can cite them as being crucial for most types of applications:
Unit testing of server-side code is essential in making sure business logic is correct, and that programmers get a safety net that prevents the introduction of regressions.
- Unit testing. Unit testing of server-side code is essential in making sure business logic is correct, and that programmers get a safety net that prevents the introduction of regressions.
- Integration testing. Similar to unit testing, often down to the tools used, but integrates with real external dependencies—such as databases or message brokers—instead of stubbing them out. Integration testing is vital to making sure the integrations between your code and its dependencies work as intended.
- API testing/endpoint testing. Consists of calling an API’s endpoints and ensuring the HTTP status codes and payload you got back are what was expected.
- Performance testing. Performance testing is in itself a huge umbrella term with many different types of testing under it, such as load, spike, and stress testing.
- Database testing. Database testing can also include a number of variations, such as automated testing of schema and data migrations, testing of stored procedures and other database artifacts, and, of course, performance testing for databases.
- Contract testing. This can go both ways: ensuring your services/APIs honor the contracts they have with their clients, and also ensuring the third-party APIs you consume don’t break their contracts/interfaces with you.
The backend testing process
There can be no unified backend testing process for the same reasons we can’t have a standardized list of key components: the approach needed varies according to each scenario. But what we can do is imagine a specific scenario or use case and then explain what a recommended process would be for that scenario.
So, suppose our application under test is a RESTful API. It’s no mere CRUD API, but instead contains significant business logic. Data is persisted to a PostgreSQL database.
What could we use as the backend testing process for this system?
Starting with development, you could use an outside-in test-driven development (TDD) style, in which you start by writing automated API acceptance tests targeting a yet nonexistent endpoint. Since the endpoint doesn’t exist yet, the test would fail.
You’d keep this test failing and start a phase consisting of potentially many “internal” TDD cycles:
- You write a failing unit test
- Write the code to make the test pass
- Refactor if necessary
- Repeat
As you go about this, you’d stub out the dependencies needed. After you have all of the business logic implemented for the first endpoint, you’d write code to integrate with real dependencies.
Then, it’s time to write integration tests that validate that these integrations work well. You could use TDD cycles at this point or not—dealer’s choice.
After the features for this first endpoint are finally complete, the “external” TDD cycle would pass to the green phase, since the acceptance API test would finally pass.
After the endpoints necessary for a first release are done, you’d deploy your API to production, and at this point, implement performance tests that target the live application.
Conclusion
Backend testing is necessary for all software applications that have a backend. Without it, you’d possibly be shipping code to production riddled with bugs, data corruption issues, poor performance, and more.
As you’ve seen, rather than being a single, specific type of testing, backend testing is an umbrella term that includes many types of testing. Which ones you’ll end up using depends on the nature and complexity of your specific setup. Nonetheless, for a software professional, it’s valuable to know at least the fundamentals of those types of testing and how you can bring them together into a cohesive backend testing strategy.
This post was written by Carlos Schults. Carlos is a skilled software engineer and an accomplished technical writer for various clients. His passion is to get to the bottom (the source) of things and captivate readers with approachable and informative technical content.