New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Http header validation skipped #201

Closed
mikeloll opened this Issue Feb 8, 2017 · 12 comments

Comments

Projects
None yet
3 participants
@mikeloll

mikeloll commented Feb 8, 2017

I'm using cucumber and xml step definitions with the http module. I can send a request just fine, however in my second step when I have a <http:receive-response /> I cannot validate headers. I explicitly set a header to an expected value which is not returned and the test still passes.

version: 2.6.2

<step then="^it should fail$">
  <http:receive-response client="myClient">
    <http:headers status="201" /> <!-- should fail, returned code is 200 -->
  </http:receive-response>
</step>

The steps execute correctly. Just not the validation.

Am I not using this correctly?

@christophd christophd added this to the v2.7.1 milestone Feb 9, 2017

@mikeloll

This comment has been minimized.

mikeloll commented Feb 9, 2017

I'm relatively new to your project but might have some cycles to fix this if you could give me some pointers.

@christophd

This comment has been minimized.

Member

christophd commented Feb 9, 2017

I am on this verifying if this is a bug. I come back to you as soon as I have answers

@mikeloll

This comment has been minimized.

mikeloll commented Feb 9, 2017

Thanks.

I also cannot get a regular xml test (non-cucumber) to work with http.

<http:send-request client="myClient">
  <http:GET path="/" />
</http:send-request>

<http:receive-response client="myclient">
  <http:headers status="400" /> <!-- should fail, actual response is 200 -->
</http:receive-response>

The above runs to completion and logs the <testcase /> as successful. My assumption is that it should fail (since I know the URL myClient is connecting to is returning 200 via citrus logging).

Thank you.

@christophd

This comment has been minimized.

Member

christophd commented Feb 9, 2017

Ok, I verified with Java DSL and this is working. I get

Validation failed: Values not equal for header element 'citrus_http_status_code', expected '201' but was '200'

Seems to be a XML DSL issue, I check ...

@christophd

This comment has been minimized.

Member

christophd commented Feb 9, 2017

Identified the problem. You need to give a body element even if it is empty. Only with this body element the header validation takes place.

<http:receive-response client="myclient">
  <http:headers status="400" /> <!-- should fail, actual response is 200 -->
  <http:body type="plaintext">
    <http:data></http:data>
  </http:body>
</http:receive-response>

This should be changed for improved usability reasons. In the meantime you need to add the empty body though.

@christophd christophd changed the title from Cucumber and Http module to Http header validation skipped Feb 9, 2017

@christophd

This comment has been minimized.

Member

christophd commented Feb 9, 2017

I changed the title of this issue to "Http header validation skipped"

@mikeloll

This comment has been minimized.

mikeloll commented Feb 9, 2017

Thank you. In this particular case I don't do any body validation, but I can do a simple @contains()@ call to essentially be a no-op for me. I've successfully validated against the header.

Most of the time this won't be an issue for me as I will primarily be using this to validate json return values etc. Thank for looking into this.

I could take a look at this over the weekend if you like.

@mikeloll

This comment has been minimized.

mikeloll commented Feb 9, 2017

Also, I think this is related to #197.

@in026hoe

This comment has been minimized.

in026hoe commented Feb 20, 2017

I'm having the same issue of my status code validation not failing when I expect it to do so. The http_reason_phrase is behaving correctly.

<receive endpoint="endpoint">
    <message type="json">
        <validate>
            <json-path expression="$..Element[0].elementId" value="1000"/>
            <json-path expression="$..Element[0].url" value="/url"/>
        </validate>
    </message>
    <header>
        <element name="citrus_http_status_code" value="200"/>
        <element name="citrus_http_reason_phrase" value="OK"/>
    </header>
</receive>

I'm also new to Citrus, is there something that I am missing?

@christophd

This comment has been minimized.

Member

christophd commented Feb 20, 2017

The bug has not been fixed yet. As workaround please add empty expected http body data so the header validation is activated

@christophd

This comment has been minimized.

Member

christophd commented Feb 20, 2017

Two possibilities here: 1st keep using the non-http receive syntax:

<receive endpoint="endpoint">
  <message type="json">
    <data></data>
    <validate>
        <json-path expression="$..Element[0].elementId" value="1000"/>
        <json-path expression="$..Element[0].url" value="/url"/>
    </validate>
  </message>
  <header>
    <element name="citrus_http_status_code" value="200"/>
    <element name="citrus_http_reason_phrase" value="OK"/>
  </header>
</receive>

2nd use the http-syntax:

<http:receive-response client="endpoint">
    <http:headers status="200" reason-phrase="OK"/>
    <http:body type="json">
      <http:data></http:data>
      <http:validate path="$..Element[0].elementId" value="1000"/>
      <http:validate path="$..Element[0].url" value="/url"/>
    </http:body>
</http:receive-response>
@in026hoe

This comment has been minimized.

in026hoe commented Feb 20, 2017

Ah thanks a lot! I was trying some things, one of which is the one you just pointed out (adding <data> to the <receive>) and after doing this the validation was working perfectly, even after removing <data> again. I didn't know what was happening and couldn't reproduce the issue I had earlier so that's why I removed my comment, hoping that I wouldn't waste any of your time.

Anyway, you did answer and your answer is helpful to me so thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment