Invocation sequence testing

[KrisJelbring]

Hi,

Newbie question/request here. I just started porting a smaller project over from Sinon to TD. Coming from the Java world and Mockito I really prefer TD's approach.

What I haven't been able to figure out is if there's any way to test the sequence of calls like you can with Sinon's calledAfter/calledBefore. I was hoping to find something similar to Mockito.inOrder.

E.g.

val first = td.function();
val second = td.function();
val inOrder = td.inOrder(first, second);
inOrder.verify(first());
inOrder.verify(second());

Is this something that does exist but isn't covered by the documentation? If not, please consider this a feature request.

[searls]

This does not exist, so far by design. My issues with it:

1. So far I have seen scant few examples where the order of two calls truly matters and for which the dependencies are side-effect-only (e.g. no return value stubbing that indirectly demands an in-order execution)
2. The API will always be a little confusing, especially if it can handle in-order invocations across multiple mocks. For instance, in your example above, what if I need four in-order verifications of the same test double? Would I have to do td.inOrder(first, first, first, first)? If I didn't call inOrder.verify four times after that, would it explode?
3. Given (2), running assertions against the td.explain(first).calls array is typically going to be more clear than a clever API would be IMO and underscore the fact that (1) there aren't very many non-weird use cases for this

If you'd like this to be incorporated into td.js, I'd love to see some examples of production functions that you think demand in-order verification

[KrisJelbring]

Thanks for taking the time to respond to my request.

In my project, I'm using Restify to construct a REST API.

In Restify you mount response handlers to an API path + an HTTP method, like this:

function respond(req, res, next) {
  res.send('hello ' + req.params.name);
  next();
}
server.get('/hello/:name', respond);

These handlers can be chained. Which is where the next() method call comes in. In most cases you call next last in your handler method to ensure any logic that you want to perform to deal with the request is handled before and not after the request has been passed along to the next handler. So in this very simple case you would test that res.send is called before next.

My initial suggestion was merely a "TD translation" of the Mockito way of doing things. In Mockito the inOrder method takes in a single instance of each of the test doubles that needs to verified but it's the order of the inOrder.verify calls that actually determine the expected order.
So in your example the call would still be td.inOrder(first). For subsequent calls on the same test double it would look something like this:

val firstObject = td.object(['a', 'b']);
val second = td.function();
val inOrder = td.inOrder(firstObject, second));
inOrder.verify(firstObject.a());
inOrder.verify(firstObject.b());
inOrder.verify(second());

I do agree though, things could definitely be made more clear. Perhaps something like this
td.verify(td.inOrder(firstObject.a(), firstObject.b(), second())); or this td.inOrder(td.verify(firstObject.a()), td.verify(firstObject.b()), td.verify(second())); would work better.

[woldie]

Maybe we could just extend the current verify API allow for variable argument lists of __rehearsal__, [ options ] pairs?

Something like:

td.verify(
    resolveSessionId1(lockSessionId1), { times: 1 }, 
    resolveSessionId2(lockSessionId2), { times: 1 },
    resolveSessionId3(lockSessionId3), { times: 1 }
);

We might need to suppress the standard console warning when testdouble detects that a stubbed invocation is also being verified in the case a verify sequence is supplied. My reasoning is that sequence could be an interesting thing to observe for intermediate mock interactions within the system under test.