Handle all remaining requests the same way

[kylealanhale]

When I've stubbed out a request or two, the framework properly lets me know all of the rest of the requests that went through un-stubbed, and fails the test. That's a useful feature, but sometimes I know that I've stubbed what I need to test, and can safely let all other requests fail/succeed in the same fashion, regardless of their HTTP method.

Now, perhaps there usually shouldn't be other requests going on, but I have a use case where the app I'm contributing to has calls to the outside world as a part of app initialization. That's questionable practice, but I can't do anything about it here.

Here's what I'm doing now to handle that:

typedef void (^ResponseWithDoneMethod)();

@interface LSStubResponseDSL (Done)
- (ResponseWithDoneMethod)done;
@end

@implementation LSStubResponseDSL (Done)
- (ResponseWithDoneMethod)done
{
    return ^() {
        stubRequest(@"GET", @".*".regex).andReturn(400);
        stubRequest(@"POST", @".*".regex).andReturn(400);
        stubRequest(@"PUT", @".*".regex).andReturn(400);
    };
}
@end

//...

- (void)testSomething
{
    //...
    stubRequest(@"GET", @".*?/some/path".regex).
    andReturn(200).
    withBody(@"{\"key\": \"value\"}").
    done();
    //...
}

This allows me to only test the endpoint in question, and ignore everything else.

It isn't a very flexible approach, but it does what I need. Is there a way that something like this can be built in that will allow us to handle all remaining unstubbed requests in a defined way, rather than failing the current test? Maybe something like this:

- (void)testSomething
{
    //...
    stubRequest(@"GET", @".*?/some/path".regex).
    andReturn(200).
    withBody(@"{\"key\": \"value\"}").
    end().
    andReturn(400);
    //...
}

This could perhaps provide a way to take care of #2:

- (void)testSomething
{
    //...
    stubRequest(@"GET", @".*?/some/path".regex).
    andReturn(200).
    withBody(@"{\"key\": \"value\"}").
    end().
    andAllowRemaining();
    //...
}

Thoughts?

[luisobo]

This will add a lot of unneeded complexity to the API. I have the exact same problem and this is what I do: http://stackoverflow.com/a/7290998

Let me know if it does not cut it.

[kylealanhale]

Thanks for the link. Still, that was just one example of where this would be useful, and wasn't really the point of filing this issue. I was trying to think of a general solution that would help in many scenarios. I think that a lot of people will have testing needs that would be benefitted by being able to handle all remaining requests the same way.

Why "unneeded complexity"? Again, you need to increase complexity already to answer the needs of issue #2; why not provide a common API for catch-all handling? Maybe a better approach than my chained one would be adding a new top-level command analogous to stubRequest, like stubAllRequests.

Another place this would be useful that I just thought of is simulating service outage:

- (void)testSomething
{
    //...
    stubAllRequests().
    andReturn(503);
    //...
}