Functional API Testing — How to Do It Right
Functional API Testing — How to Do It Right
Testing used to take place on the GUI level, but developers have since realized how fragile it is. Read more here API testing and how you can make it work best.
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
API, or application program interface, is a system of communication methods that gives developers and non-developers access to programs, procedures, functions and services. The most common protocol used in API is HTTP, together with REST architecture. Developers who program using REST make their code easy to understand. They and others know which language they will be using, how the functions work, which parameters can be used, etc.
Popular frameworks for developing APIs include Swagger, WADL and RAML. Ideally when programming, developers form a "API Contract", which describes how the services developed in the APIs should be consumed.
Prior to this standardization, programming was like the Wild West. Developers gave access to their code in the way they saw fit, and it was hard to develop public services and make them available because there were many ways to code. SOAP was the first attempt at standardization, but now REST is the dominant player.
API testing creates a more reliable code. But historically, testing would take place at the GUI level. When a developer would finish their work, they would hand it off to the QA engineer. The engineers had limited time so they would test the code at the highest level, the GUI. This would cover both the frontend and the backend development.
This worked for manual testing and for the beginning of automation testing, but isn't right for the age of agile and continuous testing. GUI testing is too brittle and GUI automated scripts break easily. In addition, teams can't wait for the entire system to be updated and the GUI to be ready before testing occurs.
In the age of agile, testing must take place at a lower level, i.e at the API level. Developers can even do it themselves. API tests, because of "API contracts", can even be created before development is complete. This means developers can validate their code based on pre-written tests (aka Test Driven Development).
But despite the known importance of API testing, it doesn't always get done. Agile Developers just don't have time. On average developers only code one day a week, the rest of their time is taken up with testing, documentation, validation, and meetings. So they try to have hardening sprints (that isn't really agile, is it?) where manual testing takes place, but it just takes too long. It's very difficult to be able to get functional API testing done in the two weeks you also need to develop, test, validate and get the documentation complete.
Automating API testing makes developing faster and clears up developers' time to do other things, like write code. Automating also enables covering the full scope of tests more easily: positive, negative, edge case, SQL injection, etc. This ensures nothing is left to chance and all parameters and permutations are tested. Agile development groups that attempt to test their APIs might test one or two positive test flows, or one positive and one negative, and call that a success. But this is not thorough API testing and opens the door for unnecessary release risk because many variants are missed and full validation isn't achieved.
For example, let's say an API takes an author's name and a book release date. A positive flow will test the name and date and see if they work. Once the response is properly received the API works. Supposedly.
But what about the negative and edge cases? Fro example, inserting a proper date but no book, or changing the date format, or a correct date format for a year that doesn't exist, or a long name, or inserting a SQL code that grants data to the DB, etc. These are just a few examples out of many variants that need to be tested, even though they are not covered in the contract.
Developers and testers need an easy way to create tests that cover all of these aspects. We recommend you look for a solution that can take your Swagger or other framework files, test them comprehensively according to your API contract, and run them as part of your Continuous Integration process. This ensures you can focus on developing strong and durable code.
Published at DZone with permission of Stephen Feloney , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.