Comments (7)
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.
- 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.
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.
Related Issues (20)
- Improve error message given when a property is only exposed as a getter HOT 3
- Throw meaningful error message when trying to return non-objects from stub used as constructor HOT 1
- Improve error message for immutable descriptors to include link to article HOT 1
- Spies for property accessors are not automatically cleaned up
- Use sinon to mock node-mssql HOT 1
- No useRealTimers() or runAllTimers() ? HOT 1
- I can't find the CHANGELOG HOT 9
- Elaborate on "For the stubbing to work, the stubbed method cannot be destructured, neither in the module under test nor in the test." HOT 5
- Unable to install [email protected] HOT 6
- Remove unused/meaningless exports and modules from the codebase HOT 1
- Limit assertion log to a reasonable default HOT 1
- `returns` not override `callThrough` HOT 4
- `returns` clears fake's `callArgAt` HOT 5
- Discrepancy in stub construction methods HOT 4
- Feature Request: Add API support to stub a parent class constructor. HOT 4
- .rejects doesn't match documentation HOT 2
- SyntaxError: Unexpected token . -> assert(opts?.sinonXhrLib, "No XHR lib passed in"); HOT 1
- Documentation of callIds
- Cannot stub private methods in native JavaScript classes HOT 1
- Calling replaceGetter invokes the original function HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sinon.