sinon

Testing routers in backbone.js properly?

点点圈 提交于 2019-12-03 01:56:52
问题 So I've just started to write tests for my in-progress javascript app, using sinon.js & jasmine.js . Works pretty well overall, but I need to also be able to test my routers. The routers, in their current state, will trigger an number of views and other stuff, terminating the current jasmine.js test by invoking Backbone.navigate dependent on application state and UI itneraction. So how could I test that routing to different locations would work, while keeping the routers "sandboxed" and not

Stubbing a React component method with Sinon

懵懂的女人 提交于 2019-12-03 01:23:29
I'm trying to stub a React component method for testing purpose: var Comp = React.createClass({ displayName: "Comp", plop: function() { console.log("plop"); }, render: function() { this.plop(); return React.DOM.div(null, "foo"); } }); var stub = sinon.stub(Comp.type.prototype, "plop"); React.addons.TestUtils.renderIntoDocument(Comp()); sinon.assert.called(stub); // throws This sadly keeps printing "plop" onto the console… and the assertion fails. Note: Directly stubbing the spec object method works, but then you have to export the component constructor and the spec separately so they're both

Proxyquire, rewire, SandboxedModule, and Sinon: pros & cons

不想你离开。 提交于 2019-12-03 01:00:49
问题 When mocking Node dependencies, I've happened upon the following libraries: Proxyquire Rewire SandboxedModule Sinon They all seem to do more-or-less the same thing: allow you to mock require() calls (with the exception of Sinon which mocks pretty much everything). They all seem to require some pretty elaborate setup, noting the exact syntax of the string passed to require -- not great during refactoring. What are the pros and cons of each library? When would I choose one over the other? What

Sinon error Attempted to wrap function which is already wrapped

久未见 提交于 2019-12-02 19:48:19
Though there is a same question here but I could not find answer to my problem so here goes my question: I am testing my node js app using mocha and chai. I am using sinion to wrap my function. describe('App Functions', function(){ let mockObj = sinon.stub(testApp, 'getObj', (dbUrl) => { //some stuff }); it('get results',function(done) { testApp.someFun }); } describe('App Errors', function(){ let mockObj = sinon.stub(testApp, 'getObj', (dbUrl) => { //some stuff }); it('throws errors',function(done) { testApp.someFun }); } When I try to run this test it gives me error Attempted to wrap

How to write test that mocks the $route object in vue components

给你一囗甜甜゛ 提交于 2019-12-02 18:07:27
I have a component that contains statement like this.$route.fullPath , how should I mock value of fullPath of $route object if I want to test that component? Best not mock vue-router but rather use it to render the component, that way you get a proper working router. Example: import Vue from 'vue' import VueRouter from 'vue-router' import totest from 'src/components/totest' describe('totest.vue', () => { it('should totest renders stuff', done => { Vue.use(VueRouter) const router = new VueRouter({routes: [ {path: '/totest/:id', name: 'totest', component: totest}, {path: '/wherever', name:

Understanding Sinon.js's yield(), yields(), and callsArg()

一世执手 提交于 2019-12-02 17:59:50
What is the difference between stub.yield([arg1, arg2, ...]) spy.yields([arg1, arg2, ...]) stub.callsArg(index) in the Sinon.js stub library? stub.yield() is the only one that I've been able to grasp: stub = sinon.stub(API, 'call_remote'); callback = sinon.spy(); API.call_remote('help', callback); @stub.yield( "solution!" ); @stub.calledOnce.should.be.true; @callback.calledOnce.should.be.true; @callback.args[0][0].should.eql( "solution!" ); As tested with should.js, would have all assertions pass. Are there similar test patterns for stub.yields() and stub.callsArg(index) ? The documentation

Sinon JS “Attempted to wrap ajax which is already wrapped”

梦想与她 提交于 2019-12-02 17:23:04
I got the above error message when I ran my test. Below is my code (I'm using Backbone JS and Jasmine for testing). Does anyone know why this happens? $(function() { describe("Category", function() { beforeEach(function() { category = new Category; sinon.spy(jQuery, "ajax"); } it("should fetch notes", function() { category.set({code: 123}); category.fetchNotes(); expect(category.trigger).toHaveBeenCalled(); } }) } You have to remove the spy after every test. Take a look at the example from the sinon docs: { setUp: function () { sinon.spy(jQuery, "ajax"); }, tearDown: function () { jQuery.ajax

Testing routers in backbone.js properly?

偶尔善良 提交于 2019-12-02 15:33:35
So I've just started to write tests for my in-progress javascript app, using sinon.js & jasmine.js . Works pretty well overall, but I need to also be able to test my routers. The routers, in their current state, will trigger an number of views and other stuff, terminating the current jasmine.js test by invoking Backbone.navigate dependent on application state and UI itneraction. So how could I test that routing to different locations would work, while keeping the routers "sandboxed" and not allowing them to change route? Can I set up some sort of mock function that will monitor pushState

Proxyquire, rewire, SandboxedModule, and Sinon: pros & cons

风流意气都作罢 提交于 2019-12-02 14:21:30
When mocking Node dependencies, I've happened upon the following libraries: Proxyquire Rewire SandboxedModule Sinon They all seem to do more-or-less the same thing: allow you to mock require() calls (with the exception of Sinon which mocks pretty much everything). They all seem to require some pretty elaborate setup, noting the exact syntax of the string passed to require -- not great during refactoring. What are the pros and cons of each library? When would I choose one over the other? What are example use-cases where each library excels? What are other products in this space that are better?

Stubbing method in same file using Sinon

流过昼夜 提交于 2019-12-01 16:54:35
I'm trying to unit test a function in a file while stubbing another function in the SAME file, but the mock is not being applied and the real method is being called. Here's an example: // file: 'foo.js' export function a() { // ..... } export function b() { let stuff = a(); // call a // ...do stuff } And my test: import * as actions from 'foo'; const aStub = sinon.stub(actions, 'a').returns('mocked return'); actions.b(); // b() is executed, which calls a() instead of the expected aStub() Some restructuring can make this work. I've used commonJS syntax. Should work in the same way in ES6 as