How and where to test if the JSON request objects generated by the front-end is valid

Question

We have built a complex Angular application that sends multiple HTTP request to a REST service that is also built in house.

Since both the frontend and the backend is being developed in parallel, bugs can happen in either side. It could be a bug in the REST service, or it can be a problem with the HTTP Request generated from the front-end. When a bug has been reported, it's important to identify where the error occurs.

There are specific structures for each of the requests. The data models are mostly populated when the users give inputs in a form or a directive

How do we approach testing these HTTP requests?

• Can we only rely on unit tests?
• Can the testing be done with dummy data that produces a pre-defined JSON object?
• Or should integration tests be done with the actual data?

And by which ever method we pick, how do we identify where the error lies when there is a bug?

Answer 1

Tests of this sort have two distinct parts - insert controlled, repeatable, known data on one side of the pipe and getting it out on the other; and validating that that data that you got out of the other end is the right data.

In the context of this environment, that means generating dummy data that is fed through your application and getting it out on the other end. The validation of the data is then done with something like jsonpath which can validate that the data is properly formatted and contains the proper information.

The key point is to take the known data through the system and test it. This isn't live data from a database, or even necessarily from a database. Rather it is data that is known to test the edge conditions of the software.

Answer 2

Given the parallel development:

• Front end (UI/browser/javascript) for behavior and data correctness can and should be tested. To support that you can develop or re-use frameworks/tools that exist to support UI behavior (click and expected results), UI content for validating field lengths, alpha vs. num, etc. and finally either stubbing (also know as mocking) external calls to the planned but not yet integrated back-end
• Back end (please specify language/platform) you will need something that drives contrived data and the scale of expected volume to the REST API. For code level unit testing there is a great amount of tools but knowing the language will be helpful.
• Integration Testing - This is the end-to-end testing when you remove the stubs between the front-end and the back-end. You could automate this with tools that support contrived data feeds (or algorithms).
• Trial Testing - This is where real world data can come into play. Depending on the sensitivity/exposure issues with the data content you may need to "scrub" the data prior to testing.

With respects to identifying error root cause this may be somewhat fuzzy but usually employing a classifications scheme at the high level works. For example:

• UI Core - Errors/Exceptions associated to the layout, design, control behaviors or logic only existing in the browser/javascript/browser technologies
• UI I/O - Errors/Exceptions associated with the generation, calling exception or receipt processing of content
• Backend I/O - Errors/Exceptions in the initial handling, formatting, preparation of inbound messages at the REST API point
• Backend Core - Errors/Exceptions in the core processing component(s) of the services

If all this is new I would suggest keeping it as simple as possible and let need drive extending the model. Of course this may mean some rework of the categorization and collection systems (JIRA?) but the cost/benefit analysis is up to you.

Answer 3

If your question is about how to enforce that both layers (frontend and backend) "talk" using the same JSON, you can try using json-schema validation.

Catching all bugs is impossible, and obviously the schema doesn't cover everything and has limitations, but you can at least make sure both layers agree on the formatting of the json. Using a schema you can specify which fields are expected, which are optional, their types, etc.

In order to troubleshoot problems, you can use online schema validators (here is one, but there are others) to see if your frontend is producing conforming json.

Answer 4

Have you considered using XML rather than JSON? XML has several robust and mature solution for validation, eg. XML Schemas. JSON is generally considered the simple and lightweight alternative to XML, but it is only simpler if you don't need the more advanced features of XML, like validation.

With an XML schema you can validate the XML request and response on either side of the wire, and this makes it easy to identify where an error originates.