Web Services Need Some Testing Love, Too
When you’re first discussing development of your project, it’s natural to focus on how you would test the graphical user interface (GUI)—you can see the fields and buttons, understand the user flows, and start to visualize how you would test it.
Not so fast! The web services that power the GUI need to be tested, too.
Web services are applications that talk to other applications, such as other services, databases, websites, and mobile apps. For a standard website, these web services have business logic and communicate between the user interface and the back end (such as a database or messaging system). Sometimes, the web service is provided by a third party, and you’ll need to test how it interacts with your own services and systems.
Web services are generally done before the GUI, so you can test the business logic sooner. If the web service will ever be available to other consumers, the front-end validations on your website won’t matter anymore—you need to make sure that your web service sanitizes inputs and safeguards itself, not just the GUI.
Testing web services is the “integration testing” section smack in the middle of the test automation pyramid. These tests are faster to write and run, are easier to maintain, and provide huge value.
You can perform a lot of the same tests against a web service that you do against a GUI, including boundaries, required fields, data types, and security testing. You can use the same heuristics you’ve always used with the GUI testing, too.
You may be wondering, how do you test something that doesn’t have a GUI? There are a bunch of free tools out there, such as Postman, that give you a kind of GUI for your web service where you can perform your testing.
If, for instance, your web service has a call to add a user with a username and email address, you could test that in the GUI by making a call to your web service with the required fields missing, submitting with invalid data (such as the email address), or sending a username that’s 1,024 characters long. You should get a message back from the web service that it’s a bad request (a 400 HTTP status code); if your web service responds with a 500 error, it’s not ready for prime time.
And if you want to automate, most unit testing frameworks have the ability to do integration tests. They simply need to call the web service, and you need to be able to read the response in your code and assert on the results. Automation is great for boundary testing or trying a bunch of different data and seeing where the web service fails. You can also make sure those third-party web services are still what your web service expects.
Add web service testing to your toolkit to improve the quality of your application, find interesting bugs that don’t exist in the GUI, and give web services some love.
Hilary Weaver-Robb is presenting the session Testing RESTful Web Services at STARWEST 2017, October 1–6 in Anaheim, California, and at STARCANADA 2017, October 15–20 in Toronto, Ontario.
