API Test Checklist
Verbs / Actions / Methods
What documentation exists ?
What functionality it provide ?
Does it support concurrency ?
What are the API endpoints ?
Is the API internal or external ?
Which endpoints are idempotent ?
Are endpoints stateless or stateful ?
Do any ...
For the REST service testing Postman and HttpMaster are good tools. It supports dynamic parameters, validation of response data, various data viewers, etc. If you are looking for performing load testing of the REST services than Grinder and JMeter open source tools can be considered.
This data is taken from the post
Tools for REST webservice testing
I really like this question, it's something I've thought about a lot. Validation response codes and a JSON body is a good start, but like you said, there's a lot more that can be done.
I built an API testing tool Assertible (https://assertible.com), and have written a few blogs on approaching different ways to test/validate a REST API, these are some of the ...
If you would love to test REST API then I would recommend you to use Rest Assured which is a Java Library.
It’s better to create Page Object Model and use Testing Framework like TestNG to write tests. Along with the main library ( REST ASSURED) that you can use for testing REST API.
Below is the official guide for the same:
The tests serve different purposes. Overlap is good.
The 'overlap' of higher order tests (such as API) and Unit tests should be high. In fact 100% would be good.
Unit tests mock and stub all dependencies. API tests do not. API tests may involve calling many units via the initial call. A unit test should test only one unit. Unit tests are involved in TDD ...
This depends on what type of testing you implement:
If it is a component testing (or if your goal is to test the particular end-point) you should isolate your component from the possible impact of other components. So having no options to mock the data I would use direct database access.
If it is an integration testing then I would use endpoints to obtains ...
I would approach with just refactoring the code to use restLibTwo. Here are few points on why I would do that:
Rest calls are just HTTP calls. Moving to another lib (for example RestAssured) would be likely motivated by surrounding functionality (like using gherkin notation or integrated json/xml parsing). So usually nobody tests REST with the lib that just ...
You have to import the RestAssured class incl. method as static.
import static com.jayway.restassured.RestAssured.expect;
Or you call the method on this way:
What questions should I ask the developers so that i can proceed with
It depends what kind of test you want to have, if it is only end2end testing then "Base URI" should be enough for you. If you need to test more than that (e.g Tests which need mocking), you may need to have access to the project code to add your test code there.
For automatically testing an API in a CI/CD scenario, try Runscope. It integrates with several build/deploy tools, including Jenkins (see Jenkins integration instructions here). In fact, I just put out a Jenkins plugin for Runscope that makes it super simple -- API tests are just build steps. You'll find GitHub link to plugin on second link above.
You can ...
You can take a look at Google HTTP Client Library for Java, that offers:
Pluggable HTTP transport abstraction that allows you to use any low-level library such as java.net.HttpURLConnection, Apache HTTP Client, or URL Fetch on Google App Engine.
You would need to write your own binding between Google HTTP Client API and restLibTwo. Note, however, there ...
I generally agree with @alexey-r... You should probably just re-write the code when the library changes.
Companies change libraries for a reason; new features, better features, streamlined configuration, etc. If you try to abstract too much you are:
Building your own API to connect with someone else's API
Making it difficult to take advantage of the ...
For manually testing an API, I like Postman. It's a Chrome app so it won't tie into Jenkins as far as I know.
API testing is pretty simple, though. You could write a simple framework that makes use of a Http Client that hits all your end points and performs assertions on the JSON responses.
2020 UPDATE: Postman is its own app now and you can use Newman to ...
I would suggest using an open source tool such as http://www.soapui.org/
This will allow you to send requests to your end points and, in turn, see the responses. Should you choose to extend your test from manual into automated (ie run the same test again along with other tests) then SoapUI also gives you that option.
I believe for your second question you have enough and more answers so I'm not going to touch base on it.
Coming to your first question, I.e what questions you need to ask, sharing some of my experience
A proper API testing is possible only with adequate documentation. Not sure whether your organisation has technical writers to document the features or ...
There is a tool designed for APIs testing - SoapUI, you can try it out and see how it goes.
In regards to JMeter - yes, it can be used for functional testing. If your concern is about test scripts readability and maintainability you can check out Taurus - new automated tests configuration and execution engine with clear syntax and very good reporting. You ...
Karate is a relatively new project that is specialized for testing JSON web-services and it runs on the JVM.
Disclaimer: am dev.
There are a set of demos and examples that will get you started very easily. One of the highlights of Karate is the "native" support for JSON and being able to perform a "deep equals" on two payloads.
I would suggest ReadyAPI/SoapUI NG Pro. It can be used to test and assert against the REST service.
One of the param options in the Pro version, run via command line, is to set the environment (-E) which means you can run the same suite against multiple endpoints fairly trivially as steps within your CI tool (or whichever method you prefer).
Using this tip/trick you can modify the response's header. The example shows modifying the content but you should be able to get the gist.
if( request.response == null )
// get response content
def content = context.httpResponse.responseContent
// manipulate content
content = content.replaceAll( "555", "444" )
// write it back
First of all, as it is always recommended focus on low-level test as much as possible and write high-level test as few as possible (e.g. Martin Fowler -Test Pyramid).
For high-level web-service test besides what others mentioned, I would recommend:
Frisbyjs: Easy to config and use. Suitable for end-2-end web-service
testing. No mocking/stubbing is ...
I have working in a not dissimilar industry and had the following setup;
TrainTestSuite (this might be per supplier/operator)
Both would utilize the same endpoint as the Test Suite
Within each test case I would have the following;
Properties (containing from and to locations)
PropertyTransfer (Transfer ...
REST API is just an API to a system, so the way the system responds to your request depends often not only on your request but also on the state of your system and time when you call it. So you should control those elements in your tests as well. For instance, whether money transfer request will be successful depends on whether a source account has enough ...
Looks like you've got some of the input checks.
You mention Postman, so I'm guessing no DB access?
The API returns the plaintext password? That seems bonkers
beyond the input checks you've listed, I might try an ID I know that exists vs. an ID I know doesn't exist
some response checks beyond just a JSON validation would make sense
I believe Alexey and MivaScott have provided good advice here. I would like to add some additional thoughts on why coding to use any possible REST API client may not be the best idea.
Some of this will look blunt, but it is not a criticism of you.
I think what you're trying to code is an overcompensation for mistakes that people have made when designing ...
Your testing is good. You are considering different possibilities and conducting experiments to see what happens. That is great.
I would continue that process. Here are some thoughts for you to try out. They are not answers you can copy and paste (which, as you indicate is good), they are ideas for your to try out yourself. Good luck!
Try special ...
You need to read the documentation in detail, it shows an example of a request body for PUT method:
There is no employee_ in the names of the attributes.
So an example flow could look like this:
1) create an employee with POST ...
The best reference to design your test cases is API documentation a.k.a API contract. This document describes:
How to call the APIs
What to expect from them
Generally, you can have these kind of test levels for your APIs (based on the contract):
Contract testing e.g. pack (includes your idea: schema validation)