There are many different ways to load tests an application — the right answer depends on your individual project and goals.
What are UI Load Tests?
Many load tests focus on interactions with the user interface. For instance, JMeter load tests make a request and download the server's response for analysis. You can easily see if the response was valid and how long it took to download. These tests can be easily and inexpensively scaled, as well as automated via a continuous integration (CI) server.
LoadNinja's Record and Replay Functionality – Source: LoadNinja
LoadNinja simplifies UI load testing with record-and-replay browser-based load tests. After recording a test in minutes, you can quickly scale it to tens of thousands of real browsers in the cloud to see how the application behaves under actual conditions. You can even integrate these tests into your continuous integration pipeline in a few clicks.
Easily evaluate navigation timings and other data that are sourced straight from real browsers in your load test without digging around for data. If you encounter any issues, you can dig into individual virtual user sessions and explore the DOM at any point in time. These capabilities help your team close bottlenecks much faster.
What are API Load Tests?
API load tests generate the same HttpWebRequests as UI tests, but the response is generally in a JSON or XML format. Using JMeter, you can generate API load tests in the same way that you'd generate conventional HTML load tests. The only difference is that the tests look for a properly formatted JSON file rather than downloading an HTML file.
If you're testing applications with a minimalist frontend, these load tests may be sufficient. The only downside is that these tests ignore client-side performance. A JSON server response may be very fast, but an inefficient client might degrade under load. These are some of the most common types of performance issues, and without UI tests, they're difficult to diagnose.
Some functional API testing frameworks have built-in load testing capabilities. For instance, SoapUI lets you easily create load tests on the base of your existing functional tests to cut down on time and effort. You can even visualize the results in a number of different ways to quickly pinpoint performance bottlenecks that you may need to address.
UI vs. API Load Tests
Front-end development has transformed from writing HTML and CSS to full-fledged applications that rival or surpass the backend in lines of code. As users demand more features and functionality, these interfaces are becoming increasingly complex. At the same time, back-end APIs are rapidly evolving to meet growing client-side requirements.
The most robust applications combine UI and API tests to ensure that everything is running smoothly under certain loads. In a world where applications are increasingly front-end heavy, it's important to test both sides of the equation rather than focus exclusively on one area — it's the only way to ensure an application scales well.
API layer tests confirm that information is being properly exchanged between the client, server and databases. You can test business logic with faster text execution and conduct a root cause analysis better than you can with UI tests. These tests are more focused on the correctness of the responses than the actual execution times for rendering the response.
Conversely, UI tests reflect what users are actually experiencing. They evaluate the translation of data from the API to the UI and ensure that everything is happening quickly and accurately. At the end of the day, these tests provide the best insight into the actual loading times experienced by users.
The Bottom Line
There are many ways to load test an application. In the case of single-page applications, you could choose to load test the underlying API or the client-facing UI — or both. Browser-based load tests provide the most accurate insights into the actual user experience, but API tests are still necessary to ensure the server side is scaling properly.
A great example of the importance of covering both UIs and APIs was the Level 3 Communications crash that nearly brought down the internet in 2016. According to the incident report, an employee entered a space into a text field that was interpreted as a wildcard. The issue represents both a UI and an API problem that would have required a unified approach in order to avoid it.