0

I 'd like to test a system that exposes different routes and API to have data (represented in JSON) that are then used by different client applications (iOS, Android, WebApp).

So my aim is to replicate the behavior of an application that interacts with the backend (using HTTP GET/POST requests), but staying agnostic from the view level and the client platform itself.

The behavior can be considered the same one for every client application, so at the moment I'm not interested to do end-to-end tests considering the UI, but only to be sure that the backend can provide the right data.

My final goal is to have a component that monitors that the backend is up and the data can be provided well.

Is it possible this kind of approach?

Does anyone know any tools/methodologies that can be useful?

Improve this question
3
  • Are you assuming your application behaves identically without regard to the end user's platform? Many apps dynamically change their behavior in the presence of a mobile, small-screen client versus a desktop client. (That's how the app I am testing works, for example).
    – Joe Strazzere
    Commented Jun 6, 2014 at 13:12
  • My priority is to test "endpoints" and not how the client apps work. Every app makes GET and POST requests, I want to test if the data is accessible and then make other requests according to retrieved values
    – danjok
    Commented Jun 6, 2014 at 13:44
  • I understand, but some apps take a different path through the code when they detect the client is a desktop device rather than a mobile device. If you were watching, you would see a different series of GET and POST requests coming in from different clients. Perhaps it doesn't matter for your app. You could use a tool which abstracts the client, such as cURL.
    – Joe Strazzere
    Commented Jun 6, 2014 at 14:55

1 Answer 1

Reset to default
2

Testing at the API level is quite possible, and usually well worth the effort, especially when there are multiple consumers for that API, or if the API is available for public use. There is a related question/answer you might want to read through here: How do you test a backend API

As far as tools for a REST web service, there are a number of options. You can use:

  1. A GUI tool such as SoapUI
  2. Load/performance testing tools like Jmeter.
  3. Simple manual testing using tools such as Postman (chrome plugin).
  4. Write automation code using HTTP and JSON libraries for your favorite programming language

The approach I have taken, which may be a good approach if you or someone on your team can write code would be to use an HTTP and JSON library. Examples for C# would be the built in .net http request and json.net. Examples for Java would be Apache httpclient and Jackson. You will also be using a tool like Fiddler, HTTPWatch, or Wireshark or one of the built in http traffic watchers in the browser developer tools to get the request information you need to build the requests.

The approach I typically take is:

  1. Create basic requests to all of the service endpoints
  2. Create a json schema (See http://json-schema.org/) to validate responses.
  3. Create specific test cases to validate the REST API behavior and assert on expected response values
  4. Record traffic from all of the known existing clients and create test cases based off of that traffic.
  5. Create additional tests taking into consideration potential future use of the API and edge cases.

The good thing about the json schema is that you create a contract, and get feedback immediately when that contract is broken. This would be useful for the monitoring you mentioned in your question. You could have a set of simple tests that run on a schedule and validate that the response is a 200 response code and the json returned complies to the schema.

Improve this answer
1
  • Thanks a lot for your answer! I am still defining the approach and your considerations are very useful!
    – danjok
    Commented Jun 8, 2014 at 11:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.