How to use needsCopyrightHeader method in Jest

setInterval returns a number, not a function. Try:

expect(clearInterval).toHaveBeenCalledWith(expect.any(Number))

Also, as mentioned in my comment, is misspelled in your example (not sure if actual code).

The approach I'd take would vary depending on what I was trying to test:

• If I was trying to unit test my authorization logic itself, I would almost certainly factor that logic out into something that looks like: Now I would just unit test checkCanSee completely on its own, passing in a fake Viewer object and fake data.

• If I was trying to unit test the logic in one of the instance methods of this class; say, if we had class TodoItem { getItemSummary() { return this.data.title + "(" + this.data.author.name + ")"; } } and I wanted to unit test that logic, there are a few options. In ES6, I'm not aware of an easy way to make the constructor actually private, so I could just call the constructor directly in my unit test with fake data. In another language, I'd hopefully be able to expose a method that was only visible by unit tests that would let me construct a new object with fake data. A third idea would be to extract out the unit test-worthy logic: class TodoItem { getItemSummary() { return summarize(this.data.title, this.data.author.name); } } function summarize(title, name) { return title + "(" + name + ")"; } Now I could unit test summarize on its own.

• If I was trying to end-to-end test the whole class (which includes testing the gen function), I'd ideally have a way of setting up a shimmed instance of Redis; once I configured that shim with my fake data, I can just run the real TodoItem.gen and test the resulting object.

• If I wanted to unit test the implementation of gen, I'd probably need to use that same Redis shim above, and similarly install a fake version of checkCanSee, using something like https://facebook.github.io/jest/docs/manual-mocks.html; from there, I could spy the call to Redis and to checkCanSee to make sure they are as expected, and test the various cases where Redis returns data/returns null or checkCanSee returns true/false.

• If I wanted to unit test code that consumes a TodoItem (say we have a function renderTodoItem that takes a TodoItem as an argument), I wouldn't use the real TodoItem implementation at all, I'd pass in a mock TodoItem to make sure that my unit test of renderTodoItem doesn't accidentally rely on implementation details of TodoItem.

Hope this helps!

If you are looking to test the contents of a custom error (which I think is what you are trying to do). You could catch the error then perform an assertion afterwards.

it('should throw', () => {
 let thrownError;

 try {
   fn();
 }
 catch(error) {
  thrownError = error;
 }

 expect(thrownError).toEqual(expectedErrorObj);
});

As Dez has suggested the toThrowError function will not work if you do not throw an instance of a javascript Error object. However, you could create your custom error by decorating an instance of an error object.

e.g.

let myError = new Error('some message');
myError.data = { name: 'myError',
                 desc: 'myDescription' };
throw myError;

Then once you had caught the error in your test you could test the custom contents of the error.

expect(thrownError.data).toEqual({ name: 'myError',
                                   desc: 'myDescription' });

Don't have to download any deps, just use:

Object.defineProperty(window.document, 'cookie', {
  writable: true,
  value: 'myCookie=omnomnom',
});

(writable needs to be set to true)

The delay operator does not work with Jest's fake timers because the delay operator's implementation uses its scheduler's concept of time - which is unrelated to Jest's concept of fake time.

The source is here:

while (queue.length > 0 && (queue[0].time - scheduler.now()) <= 0) {
  queue.shift().notification.observe(destination);
}

The current (non-fake) time is assigned to notifications when they are created and the current time is what the scheduler's now method returns. When Jest's fake timers are used, an insufficient amount of actual (non-fake) time will have elapsed and the notifications will remain in the queue.

To write RxJS tests using fake or virtual time, you can use the VirtualTimeScheduler. See this answer. Or you can use the TestScheduler and marble tests.

Have you tried to directly reference the submodule path?

import jestEnzyme from 'enzyme-matchers/packages/jest-enzyme';

Note that the project is a multirepository managed by Lerna, so the sub-packages provide only the source code, which still needs to be builded/compiled in order to be used.

This seems to be an ongoing issue.

With Node 10.7.0 and Jest 23.4.1, adding verbose: false to the jest config (per this suggestion) worked for me.

Edit

Now that I've gone to Jest 23.6 I also need to pass TERM=dumb as an environment variable, per Tamlyn's answer.

The solution that worked for me was to use the dynamic import babel plugin but also run jest without cache.

jest --no-cache

Unfortunately running it with cache again after that still fails the test so am not sure what's going on, but it works if I leave --no-cache. Just makes the tests slower.

You're running up against React's auto-binding feature, which caches the .bind(this) which is wrapped around your class methods. You can get your code to work by stubbing the cached version of the method in React's __reactAutoBindMap:

var Comp = React.createClass({
  displayName: "Comp",

  plop: function() {
    console.log("plop");
  },

  render: function() {
    this.plop();
    return React.DOM.div(null, "foo");
  }
});

// with older versions of React, you may need to use
// Comp.type.prototype instead of Comp.prototype
var stub = sinon.stub(Comp.prototype.__reactAutoBindMap, "plop");  // <--
React.addons.TestUtils.renderIntoDocument(React.createElement(Comp));
sinon.assert.called(stub);  // passes