I am using QUnit to do unit test for the javascript. I need to use sinon spy to test the setInterval function. I want to make sure that the function is called once after some time interval.
Things I need to test:
function bigVizInit() {
...
setInterval(updateViz, 5000);
...
}
And updateViz is a function like this:
function updateViz() {
...
}
The code I wrote for testing is like this:
QUnit.test("bigVizInit", function( assert ) {
...
var spy = sinon.spy(window, updateViz);
var done = assert.async();
setTimeout( function() {
assert.ok(spy.calledOnce);
done();
}, 6000);
...
});
And I got this Error: Attempted to wrap undefined property function updateViz().
As we can see, here the updateViz is a standalone function, so I use window as a wrapper for it.
I have also tried:
var spy = sinon.spy(updateViz);
And then the spy.calledOnce is false.
Someone has the same problem?
Fill in the issue template, so we can determine if this is a bug in Sinon
I'm having a similar problem; the documentation for useFakeTimers says that you can list functions to fake but doesn't explain what that would mean if you do vs don't. Just clarifying that in the docs would be pretty swell.
Since the original poster is not likely to get back to this one with enough detail to properly investigate it, I am closing it (after 6 months).
Documentation for useFakeTimers shows how to only fake some parts
well, given that three of those months were after I added my own explanation of what documentation would help, that seems like a less than stellar commitment to documentation quality. (Exactly what information does a request for documentation need?)
well, given that three of those months were after I added my own explanation of what documentation would help, that seems like a less than stellar commitment to documentation quality
All the maintainers have full time jobs, sorry to let you down in our spare time.
Pull requests are welcome
Yeah, I'll just file a pull request with each of my guesses about what will happen, since i have literally no idea, and you can accept whichever one is closest. I'm sure that's not a waste of your time.
@VynceMontgomery Most features/additional methods added after the original core has been written by people outside of the maintainer team, thus retroactively adding documentation is code archaeology where one has to dig into git log messages/git blame, original PRs and issues, and try to understand the original intent of the code/method/problem to be solved.
Generally maintaining this project is time-consuming work, and we use several hours each week just to handle the influx of issues and prs. That's why we ask for help in such matters, as the code archaeology can be done by _anyone_ that are willing to spare a few hours helping the fellow coder out.
@fatso83 Thanks for writing this down. I couldn't have expressed my thought any better. I have exactly NO idea what the request here is, and I also know shit about the code in question.
The original request is, indeed, unclear, but is about the fact that useFakeTimers is incompletely documented. The ticket had that fact explained and the documentation tag added, which seeme dgood -- I understand that it's not an easy thing to document or a high priority, but closing it without attempting to document it at all seems poor. (What good is a ticket system if requests for documentation are closed without addressing the problem?) with @fatso83 's comment, and left open, or a new ticket opened and this one closed, I'd have had no complaint, but closing documentation requests without documentation is not going to improve anything.
And, IMO, responding to documentation requests -- especially ones where the person has said they do not understand what the feature does -- with "pull requests welcome" is obnoxiously passive aggressive.
And, IMO, responding to documentation requests -- especially ones where the person has said they do not understand what the feature does -- with "pull requests welcome" is obnoxiously passive aggressive.
I agree
I have created https://github.com/sinonjs/sinon/issues/1485 to address the issue of the missing documentation.
Please try to keep issue discussions on topic. Feel free to create new issues and reference existing issue where relevant.