API (Are the basis of modern software development)
Here are a few excerpts from my presentation.
With the rise of continuous integration, continuous delivery API testing has become more critical now than ever.
If we genuinely want to be able to ship fast, you are going to have to change the way your team architect their applications. Using a microservices approach is a typical modern software development practice that more organizations are embracing.
Microservices and API Testing in the Real World
In a past episode of TestTalks, I spoke with Neil from Runscope and asked him how he would explain what a micro-service is.
It turns out Runscope itself uses a micro-services-based architecture.
There are close to 70 independent microservices that comprise Runscopt
For example, some of the services that they have are a discovery service, a queuing service, and mailing service, and the idea there was that they didn’t want to build one big, monolithic application that drove everything.
Using a micro-services approach allowed them to have those small, independent services be independently deployable and independently testable, which, when they all come together, culminating in what Runscope is today.
The benefit of this approach was that it helped them to scale, from an architectural perspective, with the amount of traffic they can handle and the way in which they develop software. They can have teams that only work on specific services, and those services can be completely independent of the other services that are behind Runscope.
As you can see, this modern approach to software development lends itself nicely to API testing.
What is an API?
Application Programming Interfaces (API) is a specification that acts as an interface for software components.
While most functional testing involves testing a user interface like a web page or a dot net form, API testing consists in bypassing a user interface and communicating directly with an application by making calls to its APIs.
API testing allows you to test headless technologies like JMS HTTP, databases and Web services.
API testing is sometimes called “headless” testing. Most headless testing consists of bypassing the UI and sending a request directly to an application’s backend or service and receiving a response while validating the response to ensure things are working as we expect them to.
You will hear this simple example referred to as a client/server relationship. A client makes a request by asking for a resource; the request then goes out and finds a server that can fill that request. The server locates the desired resource and sends a response back to the client.
API Testing is Critical
Here are some other reasons why API testing is critical and in some instances superior to just having an all UI-based automation only approach to testing.
- UI test can take up a ton of resources and many times are costly to maintain.
- UI test don’t comprehensively test your application. For instance, a UI test may validate the UI layer but not necessarily the system’s internals in a targeted way.
- Since a UI flow doesn’t have a one-to-one mapping to every API many things can be missed especially when the majority of the business logic resides in the API
- API testing is more precise in the ability to pinpoint root causes than a UI test because API is closer to the code
- If an API fails it easier to know what failed and what needs to be fixed since its so targeted. So its much quicker to fix
- API is automation ready – they are easier to automate and are often done before the UI that consumes them is.
- In my experience API tests are less fragile to change than GUI tests
- API test makes good candidates to reuse with performance.
I think API testing is not more used by organizations in their test plans because even though many companies claim to be agile there really still have distinct roles of dev/tester defined. So testers think devs should be doing the API test and testers may be unaware of even how to get started testing an API so they may just focus on what they know – UI automation.
One way to lower the barrier of entry into API testing is to introduce a way that allows anyone on the team to create and understand an API test.
Sometimes you just need to take your API test by the horns (bad pun). Enter Taurus.
Taurus is an open source BDD like tool that allows your teams to create easy to understand API tests.
The power of Taurus is that it allows you to write your tests in YAML.
You can actually describe a full-blown script in about ten lines of text, which gives teams the ability to describe their tests in a YAML or JSON file. The YAML is a human, readable, editable approach that enables you to describe a test in a simple text file. This is a big leap forward from the old days of having to bring up a big, heavy vendor-specific record and scripting tool.
• This should also allow more members of your team to contribute to performance tests. Also, since your test cases are written in YAML the tests are much more readable, making them easier to perform code reviews on.
• Taurus basically fits performance testing into your CI/CD pipeline much more efficiently.
• Taurus provides a sort of abstraction layer on top of JMeter, as well as some other tools like Locust, Gatling, the Grinder, and Selenium.
Michael Sage also shared some info on Taurus in our past interview:
The State of API Automation Testing
For more make sure to watch the full presentation. Dave actually does a quick demo of Taurus so that you can get an idea of what it’s all about. Also, for more info check out my interview with the folks at Blazemeter all about API testing: