With the emergence of extreme programming, test-driven development and other agile methods, UI testing have become an important part of almost every QA effort. At the same time, many applications provide application programming interfaces (APIs) to allow code-level access to functionality. These APIs, just like any other interface into the product, must be tested before they are released to the end-users. This article will examine the key similarities and differences between these two types of testing, focusing on the tools, the people involved in each, and the approaches taken to get the best results for your time and effort.
Since both API-testing and UI-testing target the code-level, we can use similar tools for both activities. The most commonly used UI-testing tools, such as the JUI test framework, can also be used to build your API testing harness.
In many organizations we’ve worked with, the UI testing and API testing activities are owned by different teams. UI testing is almost always an activity that is owned by the QA team; developers are expected to build UI tests for each of their code modules (these are typically classes, functions, stored procedures, or some other ‘atomic’ UI of code), and to ensure that each module passes its UI tests before the code is included in a build. This practice makes a lot of sense because it helps the developers solidify their code. Often times, this effort requires debugging and bug-fixing in real-time.
API testing, on the other hand, is typically an activity owned by the QA team, staff other than the author of the code. API tests are often run after the build has been created, and it is common that the authors of the tests do not have access to the source code; they are essentially creating black box tests against an API rather than the traditional GUI.
Another key difference between API and UI testing lies in the test case design. UI tests are typically designed by the developers to verify the functionality of each UI. The scope of UI testing often does not consider the system-level interactions of the various UIs; the developers simply verify that each UI in isolation performs as it should.
API testing, like other activities owned by the QA team, must consider the ‘full’ functionality of the system, as it will be used by the end user (in this case, another program). This means that API tests must be far more extensive than UI tests, and take into consideration the sorts of ‘scenarios’ that the API will be used for, which typically involve interactions between several different modules within the application.
So if your product contains an API that must be tested, how should you approach the task? First of all, recognize that API testing is a testing activity that happens to require some coding, and is usually beyond the scope of what developers should be expected to do. The testing team should own this activity. Secondly, recognize that traditional testing techniques such as equivalence classes and boundary analysis are also applicable to API testing, so even if you are not too comfortable with coding, you can still design good API tests. Finally, recognize that you will not be able to test all possible scenarios that are possible to use with your API. Focus your testing on the most likely usage scenarios, and also apply techniques such as Soap Opera Testing and forced error testing using various flavors of data type and size to increase your confidence in the test coverage.
