stub.firstCall.returns()

[quangv]

Hi, I believe my old specs was too verbose and implementation specific. (Before every line I wrote hand an accompany unit test... I'm assuming this is not best practice?)

I'm trying a new way of doing things, is there something like stub.firstCall.returns()

Thanks!

[cjohansen]

Just use stub.returns() and focus on the code that calls it the first time? If that doesn't work I need an example with some context to provide usable advice.

[quangv]

Kinda like, instead of

callback.withArgs(42).returns(1);

it'll be .onCall(num)

// SUT
animal = function(){
  if(callback() === 1){
    if(callback() === 2){
      return 'cat';
    }
  }
}

// Test
sinon.stub(global, 'callback')

callback.onCall(1).returns(1);
callback.onCall(2).returns(2);

result = animal();
assert.eql(result, 'cat')

Note: callback() would be a more complicated external function... (in my real code it's a database findOne...)

I could use a .withArgs but does Sinon have an onCall or similar functionality? It'll be simpler...

database.findOne({...complicated doc...}, cb)

findOne.withArgs({...gotta recreate complicated doc...}), cb).yields
...

---

Updated:

To be honest I think my code just needs to be more testable :p but .onCall is an interesting concept nonetheless

[cjohansen]

To be honest I think my code just needs to be more testable :p but .onCall is an interesting concept nonetheless

Hehe, I agree. I'm not so sure about onCall. It's interesting, but I think it will mainly be used to cover up for bad design...

[herb]

i query facebook objects and need to follow each page in the results until nothing's left. the async i/o along with the iterative nature lends itself to a recursive call, i.e.

  getAll = function(fbgraph, query, results, cb) {
    fbgraph.get(query, function (err, res) {
      results.push(res);
      if (res.paging.next) {
        getAll(fbgraph, res.paging.next, results, cb);
      }
      cb(null, results);
    });
  }

invoked like this

getAll(fbgraph, 'me/likes', [], function() { console.log("done",arguments); });

where fbgraph is criso's fbgraph library.

it seems much easier to use a onCall() function vs trying to withArgs everything to get getAll. Especially when arguments are complex objects (in the case of batch calls) withArgs seems to be touchy about matching.

How would you suggest I refactor the code to be more testable? or is this is reasonable use case for something like onCall?

[cjohansen]

I'm not quite sure how you should simplify it. You may be interested in the new matchers that's coming in Sinon 1.4 (already some information about them in the docs). They allow partial matching of object arguments.

[herb]

thanks for the reply.

I did see matchers and ended up installing master at the time which gave me
a reasonable solution to my use case. thanks!
On Apr 30, 2012 6:28 AM, "Christian Johansen" <
reply@reply.github.com>
wrote:

I'm not quite sure how you should simplify it. You may be interested in
the new matchers that's coming in Sinon 1.4 (already some information about
them in the docs). They allow partial matching of object arguments.

---

Reply to this email directly or view it on GitHub:
#105 (comment)

[Trevoke]

I have a function that does a rock-paper-scissors battle. It needs to be called a few times. Having this kind of subsequent returns would be very useful (The Ruby mocking framework mocha does this).

[cjohansen]

@Trevoke if you need more sophisticated stubbed behavior than returning a fixed value (or a value paired with some arguments), you could just do

sinon.stub(obj, "meth", function () {
    return Math.random();
});

[Trevoke]

Well, I can make this work, but it feels hackish (the solutions I will come up with for this particular problem certainly will be). I hesitate to request more behavior from sinon.js, as I do not grok Javascript yet.

[cjohansen]

My stance is that this situation is pushing the limits of how clever you want your stubs and mocks to be. So you can escape the automatic stuff and provide your own function, or you can refactor to make the tests simpler :)

[Trevoke]

You're probably right.
Thanks for being so responsive :)

On Thu, May 3, 2012 at 1:54 PM, Christian Johansen <
reply@reply.github.com

wrote:

My stance is that this situation is pushing the limits of how clever you
want your stubs and mocks to be. So you can escape the automatic stuff and
provide your own function, or you can refactor to make the tests simpler :)

---

Reply to this email directly or view it on GitHub:
#105 (comment)

[akhabibullina]

I also think "onCall().return()" might be very useful. I used them while working with phpUnit. I'd say the goal is the same as for 'withArgs()' - but applied to functions/methods that do not take any parameters.
The example is:

       $inputFile->expects($this->at(0))
                  ->method('read')
                  ->will($this->returnValue("3 4"));
        $inputFile->expects($this->at(1))
                  ->method('read')
                  ->will($this->returnValue("4 6"));
        $inputFile->expects($this->at(2))
                  ->method('read')
                  ->will($this->returnValue(NULL));

where
'$inputFile' is an object under test;
'read' is the method which should return different results on 1st, 2nd and 3rd calls: "3 4", "4 6", NULL accordingly.

Have someone the way to do this with Sinon?

[mantoni]

There is an open issue with a long discussion about this feature here: #244
If you are interested, @tf has the current state of development on a branch: https://github.com/tf/Sinon.JS/commits/tf-behavior

[akhabibullina]

Thanks!