Forum Discussion
richie
3 years agoCommunity Hero
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
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
- njetty3 years agoNew Contributor
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).