Using Target Server configuration changes to test custom 503 responses in proxy

I can use the management API to change a target server configuration to be invalid, make a "status" API call to test the 503 response and then restore the target server configuration.

This works fine when I run it as a test sequence in Postman and I plan to include it in my Apickli tests.

Question: is this a Bad, OK, Good or Best practice?

Here's the Apickli feature:

Feature: API proxy target error handling
    As an API developer, 
    I want to test error responses when the target is unavailable,
    So I know they are consistent.

Scenario: Target error response
    Given I have a valid target server connection
    When I GET /status
    Then response code should be 200
    When I have an invalid target server connection
    And I GET /status
    Then response code should be 503
    And response body path $.message should be Contact support
    Then I have a valid target server connection
0 6 520
6 REPLIES 6

Hi @Kurt Kanaskie

No doubt you need to test all scenarios. For such test cases, I would recommend to write mock tests and use that within the Apickli feature. You can use tags (something like @mock) within the test and call that separately if you need.

Or the other option is to configure another TargerServer for mock and configure this as another Target End point within your Proxy endpoint config. You can use a queryparam or a custom header in your feature scenario input which can be used to route to this mock target endpoint. With that you can test not only 503 but other cases too if there are any.

The reason I suggest this is - what if the environment you are executing the test case is used by someone. When you change the TargetServer to a different server as part of your test suite, the calls that the other app makes will also fail for that time period.

If this env is entirely dedicated for your automated testing, then it should be ok.

For either case, the safe/best approach is to do it via mock. You can use amok for the same. It is fairly simple.

Let me know if you have any questions. Will follow this post to see what others have to recommend as well.

Hi @Sai Saran Vaidyanathan,

I recognize the opportunity for calls to fail during the time the target server is changed, which prompted me to as the question. I've implemented in Apickli and it works just fine, but there are other consequences such as the test breaking and leaving the target server broken.

I've not gone down the mock path, perhaps its time.

In the first option, I understand using tags to run certain tests, but if I write mock tests, how does that execute my actual proxy policies and associated KVM settings for my real proxy?

For the other option, with a separate TargetServer for mock, I can see how that would work and is effectively a better and safer approach. I think I'll follow that suggestion for now.

Thanks

@Kurt Kanaskie

You can ignore the first option.. the first option is more widely used if you dont have a Target server and you are mocking the back end.

Right, that's what I understood. Anyway, I created a separate mock target using a custom header. That works well and the Apickli test is a lot simpler.

However, it does mean that I now have a condition evaluation for that header param on every call. I would rather not have that in production. I could maven it out, but I would like to have the same code used without modification in all environments.

Decisions, decisions. Maybe I'll go back to the target server via API management and just not run that test in production.

@Kurt Kanaskie - The condition evaluation is only for the Target Server determination and should be really negligible compared to updating the Target Server using Mgmt API.

Or how about having just one Target End Point (the actual back end) and then have a JS policy in the Target End point Request flow to set the target.url to the mock end point when the header or qp is set to mock ?

My goal is to not have anything special associated with testing in my proxy in production. So changing the target endpoint during testing seems manageable enough and leaves my proxy clean and free of testing code.

A similar approach would be to temporarily stop the backend or block access by some other means. For now, changing the target configuration in real time in the testing environment seems OK.