Is there a way to verify methods called with the 'new' operator? about sinon HOT 7 CLOSED

There's currently no API for doing that, even though the information is there. I'm not sure there is a way to be 100% sure that an object was newed, but a decent inference could check that 1) the this object in a call is an instance of the constructor, and 2) that the function did not explicitly return anything. Did I miss anything?

I guess could manually check by accessing the thisValues and returnValues arrays, but it would be better for Sinon to support this directly.

from sinon.

1. the this object in a call is an instance of the constructor, and 2) that the function did not explicitly return anything. Did I miss anything?

Nope, that's the solution I have used in the past as well, I don't think there is another way - but this should be good enough.

I guess could manually check by accessing the thisValues and returnValues arrays, but it would be better for Sinon to support this directly.

If you're interested in a patch, let me know what API you had in mind and I can give it a go. Currently evaluating if I want to use another mocking / stubbing framework or continue to work on my own stuff, this was the first thing I really needed : ).

--fg

from sinon.

You caught me in a good mood, so I added the method for you :) Hope I didn't spoil your fun, but thought I could provide some service as you're obviously window shopping stubbing tools :)

I named it spy.calledWithNew() as you suggested for now. I might change this before it's released in 1.2, I also kinda like spy.newed() or spy.wasNewed(), but I couldn't decide, so I went with your suggestion.

There's also a companion spy.alwaysCalledWithNew(), as I have for the other matchers, as well as spy.getCall(2).calledWithNew(), to check a specific call. 95f200c

from sinon.

Wow, thank you so much : ).

I named it spy.calledWithNew() as you suggested for now. I might change this before it's released in 1.2, I also kinda like spy.newed() or spy.wasNewed(), but I couldn't decide, so I went with your suggestion.

I like the current method name, but feel free to change it.

95f200c

Reviewed your patch and found an unused variable, see comment : )

One last question: I see you have this sinon.assert.callOrder() thing - how does that behave when there are multiple calls to those functions? Last call counts?

from sinon.

Thanks for actually looking through the code, highly appreciated :)

callOrder - this actually checks the first call to each function. If you have a good case for changing this behavior I'd consider it, but it has worked as expected for me thus far.

By the way, the assertions have "pluggable failability", so if you're simply using node's assert package, you should be able to do:

var assert = require("assert");
var sinon = require("sinon");
sinon.assert.fail = function (message) {
    var e = new Error(message);
    e.name = "AssertionError";
    throw e;
};

sinon.assert.expose(assert, { prefix: "" });

var spy = sinon.spy();
assert.notCalled(spy); // Passes
assert.calledOnce(spy); // Fails like normal assertions

The assertions can make for better readability in some tests in my opinion.

from sinon.

callOrder - this actually checks the first call to each function. If you have a good case for changing this behavior I'd consider it, but it has worked as expected for me thus far.

I'll have to play with it. So far I've been writing my tests using mostly mocks which always had call order expectations. I really got my defect rate down, but I want to experiment with less coupling of my tests to my implementations - so I may not even use this much.

By the way, the assertions have "pluggable failability", so if you're simply using node's assert package, you should be able to do

Yeah, that looks sweet. Any reason you don't make that the default in node?

Anyway, I I'll try to rewrite some tests for an existing project with sinon now - I'm excited : ).

Thank you for all the help!
--fg

from sinon.

I'll have to play with it. So far I've been writing my tests using mostly mocks which always had call order expectations. I > really got my defect rate down, but I want to experiment with less coupling of my tests to my implementations - so I may > not even use this much.

Yup, I tend to mostly use stubs to "silence" dependencies, and try to not assert too much on internal communication. The call sequence stuff is useful when the order of calls is an important feature somehow (in contrast to an implementation detail).

Yeah, that looks sweet. Any reason you don't make that the default in node?

Good question, guess it didn't occur to me. Will fix.

Anyway, I I'll try to rewrite some tests for an existing project with sinon now - I'm excited : ).

Cool, looking forward to hearing how you like it in practice :)

Thank you for all the help!

No problem, and thanks for the useful feedback.

from sinon.