unexpectedjs/unexpected-http

Timeout handling

Closed this issue · 8 comments

I'd like to be able to do something like this:

expect('GET http://google.com/', 'to yield response', {
    statusCode: 302,
    within: 1000
});

If it takes more than 1000 ms, the assertion should fail, and not wait for the request to finish.

https://github.com/unexpectedjs/unexpected-http/blob/master/lib/unexpectedHttp.js#L92
https://nodejs.org/docs/v0.10.38/api/http.html#http_response_settimeout_msecs_callback

We're writing a test suite to assess the state of a web application. If said web application is not responding fast enough, I'd prefer to have it be an explicit assertion error instead of an error from the test runner. When the test runner is handling timeouts, we have no way of controlling the output.

@papandreou @sunesimonsen do you have any input on the above feature request?

It makes sense for integration tests and should be completely doable.

@gustavnikolaj good idea, go for it! Do you need it to support expect.it etc. or do you just need to set an upper limit? The latter is by far the easiest -- just use a setTimeout.

I want it to be part of the unexpected-http assertion to yield response as illustrated in my code example above.

@sunesimonsen suggested to just make an assertion that asserts that a promise returns within a timeout - it sounds like you're making the same suggestion?

@gustavnikolaj that would also be useful, but I think it makes sense to make it a first class citizen here.

And it would probably make more sense as

expect({
    url: 'http://fasdjkflasdlfkjasdlkfajsdlf.com',
    within: 100
}, 'to yield response', 'foobar');

Right, if you just reject the promise with a recognizable error after within milliseconds, promise semantics will see to it that the assertion only fails if that occurred before the promise was fulfilled or rejected based on the actual HTTP response.

This issue is replaced by the above referenced PR.