Odd functional tests error

Not applicable

I am trying to figure out how to plug the deployment of xml policies into our CI tool. In order to do that I have added some functional tests, written in java using Testng and RestAssured, to the mvn plugin structure. All of my tests pass if you run them one by one, but when you run the whole suite via maven, I am getting odd results. Below is one flavor.

Odd scenario #1

I get a test failure because the status code is 500. Here is the Mvn call and the beginning of the stacktrace.

96-cistacktrace.png

The odd part is that if you do a trace of the calls i see the 16 calls and none of them return 500

95-cicalls.png

Is it possible for the status code to be changed after the it leaves the trace tool?

Solved Solved
0 2 157
1 ACCEPTED SOLUTION

Not applicable

I figured this out. I had a situation where a target service was returning a 404 for a particular use case. I wanted to change that to a 204. The problem was in the way that I went about transforming the status code. I had researched and found a way to add 404 as a success code and then handle the 404 with an 'Assign Message' policy. This method works great for a few times in a row, but then it does something to the next message coming in. This surfaced when I was running the suite of functional tests. The test for the 404 to 204 would never break, it was always the test after it. I was then able to isolate the culprit.

I figured out a different way to handle the scenario with a 'Fault Rule'. This method plays nice with the subsequent calls.

Here is the fault rule

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="Raise401">
    <DisplayName>Raise 401</DisplayName>
    <FaultResponse>
        <Set>
            <Headers/>
          <Payload contentType="application/json">{"fault": {"faultstring": "Unauthorized","detail": {"errorcode": "401 Unauthorized"}}}</Payload>
            <StatusCode>401</StatusCode>
            <ReasonPhrase>Server Error</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

View solution in original post

2 REPLIES 2

Not applicable

I have never seen this occur. Is there any other tier between your test endpoint and Apigee that might be rewriting the status code or failing the response? I have seen this occur with a MIM proxy that was left enabled...

Not applicable

I figured this out. I had a situation where a target service was returning a 404 for a particular use case. I wanted to change that to a 204. The problem was in the way that I went about transforming the status code. I had researched and found a way to add 404 as a success code and then handle the 404 with an 'Assign Message' policy. This method works great for a few times in a row, but then it does something to the next message coming in. This surfaced when I was running the suite of functional tests. The test for the 404 to 204 would never break, it was always the test after it. I was then able to isolate the culprit.

I figured out a different way to handle the scenario with a 'Fault Rule'. This method plays nice with the subsequent calls.

Here is the fault rule

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="Raise401">
    <DisplayName>Raise 401</DisplayName>
    <FaultResponse>
        <Set>
            <Headers/>
          <Payload contentType="application/json">{"fault": {"faultstring": "Unauthorized","detail": {"errorcode": "401 Unauthorized"}}}</Payload>
            <StatusCode>401</StatusCode>
            <ReasonPhrase>Server Error</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>