Sandbox seems like just the thing. Perhaps it deserves a more prominent note in the documentation (e.g. in connection with stubbing out whole objects). Thank you for your help!
And yes, I agree with you, sandbox should get more light. I had read the whole documentation plus a tutorial or two about sinon when sinon.sandbox didn't exist. When I discovered it existed by mistake, I thought that it would save me time, make code more readable and more importantly, that would save collaborators from forgeting to verify or restore spies & co.
Okay, new problem.
foo.js
const doFoo = () => { console.log('bad stuff!') }
const doBar = () => { doFoo() }
module.exports = { doFoo, doBar }foo.test.js
const sandbox = require('sinon').sandbox.create()
const foo = require('./foo')
describe('doBar', () => {
before(() => {
sandbox.stub(foo, 'doFoo')
})
it('should call doFoo', () => {
foo.doBar() // prints "doFoo" to console
})
})What gives? Why isn't doFoo mocked when doBar calls it?
@brandones If I remember well, you can only wrap functions external to the code you test.
In your test suit, you're calling a function and mocking another from the same module. That won't work; my guess is that it is because both functions are defined at the same time, giving no opportunity to sinon to wrap
Anyway, if you must mock functions from the unit you're testing, it smells bad. Either you should move doFoo to another module or you should target more precisely the dangerous section :
In your test suit, you're calling a function and mocking another from the same module. That won't work; my guess is that it is because both functions are defined at the same time, giving no opportunity to sinon to wrap
doFoo before doBar is defined.Anyway, if you must mock functions from the unit you're testing, it smells bad. Either you should move doFoo to another module or you should target more precisely the dangerous section :
sandbox.stub(console, 'log');.
for example
const aSpy = sinon.spy(object, 'method');
aSpy.wasCalled(function() {
//....do some stuff after the spied method was called
})
I have thought of using a stub, saving the original method that is going to get stubbed and then calling the original method along with other code inside a
.callsFake()
I have a problem with undefined methods on mock
My test code looks like this:
const mock = sinon.mock(new Xxx(configuration));
mock.expects('methodA').once().withArgs(sessionId, '', '', '', null).resolves(null);
new ClassUnderTest(mock, 100);ClassUnderTest calls arg1.methodA(); and fails with TypeError: arg1.methodA is not a function
in debugger I see that arg1 has methodA in expectations and proxies and I see the original object in object property
Hello all! I installed Sinon globally and my node script can't find it. I just receive a 'module not found' error. I see that it is advertised that Sinon doesn't pollute the global namespace, and I'm kind of a newb here. So, is my global installation not being found expected?
How can I mock this 'getQbo' function ?
Have this library
// quickbooks module.ts
var QuickBooks = require('node-quickbooks');
export function getQbo (token, companyId, refresh) {
return new QuickBooks(process.env.QB_CLIENT_ID,
process.env.QB_CLIENT_SECRET,
token, /* oAuth access token */
false, /* no token secret for oAuth 2.0 */
companyId,
true, /* use a sandbox account */
true, /* turn debugging on */
4, /* minor version */
'2.0', /* oauth version */
refresh /* refresh token */);
}Imported like this
// paymetn.module.ts
import {getQbo} from "./../../../utils/quickBooks/qbo.module";
Is there a way to set up the xhr expected arguements with the xhr server? say I don't have a callback coming back from the method
var mock = sinon.mock(QuickBooks);
Or you can stub just that one method like this:
var stub = sinon.stub(QuickBooks, “getQbo”);
let me know if that doesn’t work
Actually, you import the object as “getQbo”. My bad, try these:
var mock = sinon.mock(getQbo);
var stub = sinon.stub(getQbo, “getQbo”);
Hey everyone. Just curious if anyone had tips for spying on objects. I know how to spy on functions, but if you want to spy on say the request object in an Express middleware it doesn't seem as intuitive. I've tried spying on the middleware function, but when I do spy.thisValues I receive undefined
I’m not seeing anything about that here http://sinonjs.org/releases/v4.1.3/spies/
I think you might have to create multiple spies for each function on the object.
@alexesca ^
I'm trying to build an Alexa skill, I have most of the skill tested with Mocha/Should/Sinon - but they have this really weird architecture for their "Intent" code, which actually is the meat of the skill
They use "this" inside an object that isn't a class
I've tried stubbing the
response calls, I've tried to call it with .call and .apply to set what this should be, and a number of other things, but this is always {} inside the intent object
Any idea how I might be able to mock or stub the properties that the object is calling on
this inside that object so I can test if they're called?
For the lazy who don't want to go to the link, here's an example of what I'm talking about
const handlers = {
'HelloWorldIntent' : function() {
//emit response directly
this.emit(':tell', 'Hello World!');
}
};