Forum Discussion

njetty's avatar
njetty
New Contributor
3 years ago

Assert for java.net.SocketException when executing "HTTP Request" Test Step

I have a test suite that I am working on for our disaster recovery set up.  In this scenario, I expect certain HTTP servers to be offline on certain VMs.  I created a "HTTP Request" test step and thought that using a "Not Contains" assertion would do the trick.  Unfortunately, the assertion (which I am expecting to pass) fails... stating "null/empty response body".  The Log shows "java.net.SocketException" (expected).  I've used this trick for Rest services I expect to be "down/offline" and it works.  

 

Is there any way to assert that an http server is offline successfully?

Assertions
  • richie's avatar
    richie
    Community Hero
    3 years ago
    Hey njetty,

    Asserting that a service is down is kinda complicated and asserting on it and how you assert against it all kinda depends on your architecture, setup, config and the software.

    The reason why the "not contains" assertion didnt work is cos the response you got didnt include a payload.

    If you think about it...it all depends on the setup of the service youre supposed to be testing, cos if it the service wasnt running, how would it be able to respond if it was down?

    So essentially it depends how "offline" your endpoint is, what the setup is as well as if your devs have tailored the http responses to cover "offline" scenarios.

    If your endpoint is a bit offline, then other supporting tech will help provide a response indicating it's offline....say a 5xx series http response codes. However if your endpoint and the supporting tech is down, then you wont have any response at all from the endpoint....like some socket exceptions.

    Im sorry.....its not a clear answer....but it depends on the software/hardware and how "offline", "offline" actually is.


    So if your endpoint is "too offline" (rubbish phrase but i dont know what else to call it), then youll never get a response to know its down. If i remember correctly a socketException is actually generated by the client not the endpoint in certain situations....so in those situations you havent got any sort of reaponse to go on. Other not so offline situations result in reaponses being returned...5xx http responses etc.

    Does any of that help at all? Probably not much!

    Cheers

    Rich


    • njetty's avatar
      njetty
      New Contributor
      3 years ago

      Yes.. Unfortunately.  Not too helpful.  In this case the http server is completely offline.  Like.  No response period.  Hence the Socket Exception.  I just need a way to assert that this is in fact what I am looking for!  The fact that there is no service running on the endpoint is a successfully test in this scenario.  Understood… i.e. no payload, hence, “not contains” exception is not working here.  Funny though.  I have used that same assertion type on REST services and they will work for when there is zero response from the URL.  Just seems to be something with the “HTTP Test” vs. “REST Test” step types, that are not quite the same here (i.e. how the underlying engine implements them).

  • njetty's avatar
    njetty
    New Contributor
    3 years ago
    Yes.. Unfortunately. Not too helpful. In this case the http server is completely offline. Like. No response period. Hence the Socket Exception. I just need a way to assert that this is in fact what I am looking for! The fact that there is no service running on the endpoint is a successfully test in this scenario. Understood... i.e. no payload, hence, "not contains" exception is not working here. Funny though. I have used that same assertion type on REST services and they will work for when there is zero response from the URL. Just seems to be something with the "HTTP Test" vs. "REST Test" step types, that are not quite the same here (i.e. how the underlying engine implements them).




    Neil Jetty
    Senior Application Architect
    T: 905-614-3622, M: 416-487-4000
    neil.jetty@bell.ca
    [cid:image001.png@01D82CE2.A7E31DA0]

Recent Discussions