MUnit Code coverage — Non Functional Testing
So you worked on MUnit suite to test your API. You added business scenarios, success & failure cases and covered all the choice, scatter-gather branches. Still didn't get the magic number of 80% coverage that your organization mandates? Lets discuss ways out of this situation.
Playing MUnits in hard mode!
Scope
Scope of this article is limited to increasing code coverage with means other than actual functional testing. This article doesn’t involve introduction into MUnits and MUnit tools. This article doesn't involve ways to override MUnits test coverage in POM. This article will focus on munit test cases which can be used in any API flows.
How did we land here
Application coverage may not be easy in APIs where there is less business logic.
In experience APIs, we usually do not have any complex rationale, data transformation or any orchestrations.
APIs where we have exposed provider systems in a proxy use-case scenario will not have enough actionable cases to reach desired code coverage.
Or you just couldn't find any more test cases?!
Targeting the API Kit Router
APIKit router is created when we generate flows from RAML. It routes input to the available resource paths. So how about we mock it?
- Mock the APIKIT to throw errors and capture it in assert block. In this example, the mock component will throw a 404 error.
In the validation part, status can be asserted in different ways.
- Assert that
- Assert Equals
2. Mock the APIKIT router and assert a 501.
Mentioned in the below section are other 4XX error which can also be simulated here.
Targeting the HTTP Listener
Create a HTTP requestor call to the API Listener. Lets try some success and failure scenarios, make some obvious mistakes in the request and capture it. Lets assert that in validation block!
Is testing with a HTTP call a morally correct unit testing? Maybe; May not be. In our xAPI or proxy use-case scenario, there isn't any business logic. So even the end to end flow is going to have only the pAPI/backend HTTP requestor (and some loggers)? So there is only one module/function in the flow. The boundary lines do get a bit blur here. This HTTP requestor call based MUnits will work in your DevOps pipeline also.
While running MUnits, the application flow will not be running. So the HTTP requester will throw an error saying the HOST is down and not reachable. So make sure you enable the flows which has to run.
So what are the test cases:
- 404 — In the HTTP requestor give the wrong path. The path will not be found and thus the request will fail with bad request. Assert that. HTTP request path can be given as “/orde” instead of “/order” i.e. some spelling difference.
2. 405 — In the HTTP requestor call the wrong HTTP method. A PATCH method can be used in the call in place of POST. The API will throw a “method not allowed” error. Assert that.
<munit-tools:assert-that expression="#[attributes.statusCode]" is="#[MunitTools::equalTo(405)]" message="The HTTP Status code is not correct!" doc:name="Assert That Status Code is 405" />3. 415 — Call your API with input content type which is not specified in the RAML. The mime type will not be accepted and a 415 will be thrown. Assert that.
4. 406 — Reverse of the above scenario. Ask the server for wrong media type in response. Our RAML is described to produce a JSON. An accept header with XML type will throw 406. Assert that.
5. Similarly we can simulate for 401 error based on the auth mechanism implemented
What about the backend Requestor?
The backend/pAPI HTTP requestor can be targeted with similar error scenarios. The mock component for the requestor will return such errors which can be asserted.
Conclusion
The test cases discussed here is not the primary purpose of MUnit testing. But having a valid test cases such as this is better than ignoring unit test validation/ coverage in POM. Use these only to fill gaps and get over the coverage boundary. Focus more on business-oriented functional test cases. But these test cases can be used in any APIs immaterial of API purpose.
Play around!
