Now my time is split approximately 50/50 between creating automated tests for UI and creating tests for APIs like REST services. There are a few reasons for this:
- Agile practices
- The Internet Of Things
I've been involved with test automation for over 15 years, and in the beginning, pretty much all my test automation efforts focused on automating GUI user interfaces like thick client applications, browsers and even green screen for mainframes.
Agile Automation
With Agile development becoming the standard in most organizations, the ways in which we develop software and automate tests have changed dramatically.
GUI tests that go against a user interface tend to take longer to run.
During certain Agile practices like continuous builds, the amount of time it takes to receive feedback from a GUI regression suite of tests when new code is checked in is too long. In those cases, quicker feedback is needed.
Agile has also increased the frequency with which applications are released, which in turn has created an increased demand for new ways to quickly test them. GUI tests are typically too slow to get the test coverage we need during, say, a typical two-week sprint. Also, since API tests don't rely on a UI to be ready, they can be created early in the development process.
Mike Cohen's Testing Pyramid
In his book, Agile: Software Development Using Scrum, author Mike Cohn introduces the concepts of a test automation pyramid:
This image represents the opposite of the way most non-agile development teams perform automated testing.
GUI Test
GUI testing focuses on testing an application user interface to ensure that its functionality is correct. IDE GUI testing is at the top of the pyramid and represents a small piece of the total number of automation test types that should be created.
Unit Test
Unit testing makes up the largest section of the pyramid, forming a solid base. A Unit test is created to verify a single unit of source code, like a method. By doing this, developers can isolate the smallest testable parts of their code. Unit tests are the easiest to create and yield the biggest “bang for the buck.” Since unit tests are usually written in the same language that an application is written in, developers should have an easy time adding them to their development process.
Service – API Test
The middle Service layer is the “sweet spot” that tools like SoapUI, UFT API and rest-assured were created for. Service testing is also known as Integration testing. Integration testing focuses on verifying that the interactions of many small components can integrate together without issue. Since API tests bypass the user interface, they tend to be quicker and much more reliable than GUI tests.
The Internet of Things
The second change that is causing a shift towards API testing is the Internet of things. The Internet of Things is an everyday object with embedded functionality that allows it to talk over the web using HTTP or HTTPS to communicate with remote backend services.
Basically, more and more things will begin to have sensors embedded into them. The other day I saw a video of Enchanted Objects: Design, Human Desire, and the Internet of Things author David Rose being interviewed by John Stewart, who showed a medication “glow” cap, that will tell you when to take your medicine by blinking or texting you so that you don't forget. This is just one minor application, but I'm sure you can imagine the endless possibilities for this type of technology.
Extending this trend outward, some estimates show that in 2020 there will be over 50 billion objects connected to the internet!
So how do you test, say, a scale that tweets, a refrigerator that tells you when you're running low on milk, or bio sensors embedded in your clothing that can measure your stress level — and adjust your environment accordingly — based on that information?
None of these examples have a traditional user interface. So how do we test them?
First, let's look at a typical API test flow:
API Headless Testing
What is an API (Application Programming Interface)? An API specifies how its software components should interact with each other. APIs can be created using a whole host of different technologies. APIs help facilitate communication between a client and a server.
The type of APIs that we're most likely going to be testing are HTTP/HTTPS- based APIs where communication is done over the web. For example, say we have an internet scale that has an app that makes a request and receives a response from a backend service. How do we test them?
Tools to Test APIs
There are many tools available — both open-source and vendor-based. Here are a few of my favorite tools and resources to help you discover more (and prepare for the API testing revolution):
- How to Test a Web Service — three-part series
- SoapUI – How to test a web service
- REST Testing with Java: Getting started with rest-assured
- The UFT API Testing Manifesto – a step-by-step, hands-on testing guide for the masses
- Mike Giller:SoapUI and API Testing podcast interview
