I was trying to test an Angular app and the click and type related actions was not working. Finally it was solved with MouseEvent and KeyboardEvent API.

It work with both MouseEvent and KeyboardEvent. Here is example with MouseEvent.

function simulateEvent(eventx, elem) {
    const event = new MouseEvent(eventx, {
        view: window,
        bubbles: true,
        cancelable: true,
    });
    return elem.dispatchEvent(event);
};

function simulateType(selector, value) {
    const elem = document.querySelector(selector);
    elem.value = value;
    const events = ['click', 'focus', 'keydown', 'keypress', 'mousedown', 'compositionend', 'compositionstart', 'blur']
    for (let fakeEvent of events) {
        simulateEvent(fakeEvent, elem);
    }
};

It sets the value to the input field, and sends a lot of events as you can see.

Why? Some website watches for keydown, keypress etc. however, I have seen a lot of website did not even let me submit the form if I did not click on the input fields.

This seems to have been fixed.

Below is a working setup:

Versions

"jest": "~20.0.4"

"webpack": "^3.5.6"

package.json

"jest": {
  "moduleNameMapper": {
    "^@root(.*)$": "<rootDir>/src$1",
    "^@components(.*)$": "<rootDir>/src/components$1",
  } 
}

webpack.shared.js

const paths = {
  APP_DIR: path.resolve(__dirname, '..', 'src'),
};

exports.resolveRoot = [paths.APP_DIR, 'node_modules'];

exports.aliases = {
  '@root': path.resolve(paths.APP_DIR, ''),
  '@components': path.resolve(paths.APP_DIR, 'components'),
};

while jest can run async code easily, you can use promise and setTimeout combination to wait a bit. For example this code will wait for 2 seconds:

await new Promise((r) => setTimeout(r, 2000));

Full sample test. Don't forget to add async flag before the callback function:

test('some test title', async () => {
  const foo = true;
  await new Promise((r) => setTimeout(r, 2000));
  expect(foo).toBeDefined();
});

Also, keep in mind that default "timeout" is 5 seconds (5000ms). If your test may run longer, you can add jest.setTimeout(30000); above the test(). 30000 will make sure to not timeout for 30 seconds. You can add any number you need. Full example with setTimeout:

jest.setTimeout(30000);

test('some test title', async () => {
  const foo = true;
  await new Promise((r) => setTimeout(r, 2000));
  expect(foo).toBeDefined();
});

Development

If it should be always development just set it as a system variable, see Production / Staging below. If you want to run different environments during development, appending your npm run scripts is the way to go. Additionally, you can use cross-env to ensure that your scripts work on different platforms:

"start": "cross-env NODE_ENV=development ts-node -r tsconfig-paths/register src/main.ts",

---

Testing

If you want to run your integration tests in a different environment, you can set it in your jest-e2e.json:

"globals": {
  "NODE_ENV": "test"
}

Setting (or changing) your environment for one particular test can also be done in the test code:

let previousNodeEnv;
beforeAll(() => {
  previousNodeEnv = process.env.NODE_ENV;
  process.env.NODE_ENV = 'test';
});

afterAll(() => process.env.NODE_ENV = previousNodeEnv);

---

Production / Staging

On a staging or production system, I'd recommend setting it as a normal system variable, see this thread.

I found out that the problem was the rewire lib. For some reason, it was messing with the window's events. I remove it and change my code to be able to mock data variable without rewire

Version Info

As is noted in the question, property matchers were introduced in Jest 23.0.0. Note that apps bootstrapped with create-react-app as of today (Aug 5, 2018) are still < 23.

OBJECT

Here is an example using a property matcher for a single object:

test('sportsBallPerson', () => {
  expect(sportsBallPeople[0]).toMatchSnapshot({
    createdAt: expect.any(Date)
  })
});

The snapshot generated:

exports[`sportsBallPerson 1`] = `
Object {
  "createdAt": Any<Date>,
  "name": "That one famous guy from Cleveland",
}
`;

This will correctly match createdAt to any date and the name to exactly "That one famous guy from Cleveland".

ARRAY

To test an array of objects using property matchers use forEach to loop over the array and snapshot test each object individually:

test('sportsBallPeople', () => {
  sportsBallPeople.forEach((sportsBallPerson) => {
    expect(sportsBallPerson).toMatchSnapshot({
      createdAt: expect.any(Date)
    });
  });
});

The snapshots generated:

exports[`sportsBallPeople 1`] = `
Object {
  "createdAt": Any<Date>,
  "name": "That one famous guy from Cleveland",
}
`;

exports[`sportsBallPeople 2`] = `
Object {
  "createdAt": Any<Date>,
  "name": "That tall guy",
}
`;

forEach ensures that the objects are tested in order, and each object is properly snapshot tested as described above.

Additional Info

It is interesting to note that directly testing an array using property matchers does not work properly and has unexpected side-effects.

My first attempt to test an array was to create the following test:

test('sportsBallPeople as array', () => {
  expect(sportsBallPeople).toMatchSnapshot([
    { createdAt: expect.any(Date) },
    { createdAt: expect.any(Date) }
  ]);
});

It generated the following snapshot:

exports[`sportsBallPeople as array 1`] = `
Array [
  Object {
    "createdAt": Any<Date>,
  },
  Object {
    "createdAt": Any<Date>,
  },
]
`;

This is incorrect since the name properties are missing, but the test still passes (Jest v23.4.2). The test passes even if the names are changed and additional properties are added.

Even more interesting was that as soon as this test executed, any following tests using property matchers were adversely affected. For example, placing this test ahead of the the test looping over the objects changed those snapshots to the following:

exports[`sportsBallPeople 1`] = `
Object {
  "createdAt": Any<Date>,
}
`;

exports[`sportsBallPeople 2`] = `
Object {
  "createdAt": Any<Date>,
}
`;

In summary, directly passing an array to use with property matchers does not work and can negatively affect other snapshot tests using property matchers.

Turns out this is fixed (as of jest 24.1.0) and the code in the question works, as expected.

---

To recap, given class A:

A.js

module.exports = class A {
  constructor(value) {
    this.value = value;
  }
  setValue(value) {
    this.value = value;
  }
}

This test will now pass:

A.test.js

jest.mock('./A');

const A = require('./A');

A.mockImplementation((value) => {
  const rv = Object.create(A.prototype); // <- these are mocked methods
  rv.value = value;
  return rv;
});

it('does stuff', () => {
  const a = new A('some-value');
  expect(A.mock.instances.length).toBe(1);
  expect(a instanceof A).toBe(true);
  expect(a).toEqual({ value: 'some-value' });
  a.setValue('another-value');
  expect(a.setValue.mock.calls.length).toBe(1);
  expect(a.setValue.mock.calls[0]).toEqual(['another-value']);
});

The official Writing Tests doc from Redux recommends this approach:

But sometimes you want to test just the rendering of the component, without a Redux store.

In order to be able to test the...component itself without having to deal with the decorator, we recommend you to also export the undecorated component

In other words...export NavBar as a named export so you can access it in your tests.

Then you can test it directly as a simple UI component that just renders based on the props you give it.

Jest describe.each expects an array of arrays in the first parameter. If you pass in a 1D array, internally it will be mapped to an array of arrays (i.e. passing [1, 2, 3] as first parameter would be converted to [[1], [2], [3]]).

Each one of the arrays inside of the array is used as the data for a test suite. So, in the previous example, describe.each would generate three test suites, the first with 1 as data, the second with 2 as data and the third with 3 as data.

Now, in the test suite name, you can only format the parameters you are providing to it. In your case, you are passing to each test suite the data in each object of the accounts array. So, when you set the format specifiers in the test suite name, they will apply to the whole account object (i.e. the %s in your example will stringify your object resulting in [object Object]). Unfortunately, I don't think you can apply the format specifiers to a key of the object.

Some ideas to accomplish what you want:

Solution 1

If you use the %s formatter to compose the test suite name, the toString method of Object will be called (which by default returns [object Object]).

If you define a toString method in each of your accounts objects, that method will be used instead. So, we could add the toString method to each one of the account objects with this code (note that the toString method we are adding is returning the value for the type key):

const accounts = [{
    details: {
        company_name: "company_name",
        email: "aa",
        password: "asdf",
    },
    find: [ "_id", "company_name", "email", "type", ],
    type: "creator"
}, {
    details: {
        email: 'bb',
        first_name: "first_name",
        last_name: "last_name",
        password: "asdf",
    },
    find: [ "_id", "email", "first_name", "last_name", "type", ],
    type: "user"
}].map(account => Object.assign(account, { toString: function() { return this.type; } }));

Now, with the %s format specifier you should see the account type in each test suite:

describe.each(accounts)(
    "%s", // <-- This will cause the toString method to be called.
    function (account)
    {
        // test code
    }
)

Solution 2

You can always redefine each one of your test suite data so that the first parameter is the account type (note that now accounts is a 2D array):

let accounts = [
    [
        "creator",
        {
            details: {
                company_name: "company_name",
                email: "email",
                password: "asdf",
            },
            find: [ "_id", "company_name", "email", "type", ],
            type: "creator"
        }
    ], [
        "user", 
        {
            details: {
                email: "email",
                first_name: "first_name",
                last_name: "last_name",
                password: "asdf",
            },
            find: [ "_id", "email", "first_name", "last_name", "type", ],
            type: "user"
        },
    ]
]

You can now use that first parameter (which is the account type) to give the test suite its name:

describe.each(accounts)(
    '%s',  // <-- This %s will format the first item in each test suite array.
    function (accountType, account) {
        // test code
    }
); 

Note that now your test function receives two parameters as each test suite array has two elements. The first one is the account type and the second one is the account data.

Solution 3

You can use the tagged template literal form of describe.each. With this solution you don't have to change your current definition of accounts array.

describe.each`
    account
    ${accounts[0]}
    ${accounts[1]}
`('$account.type', function (account) { 
    // test code
});

The downside of this solution is that you have to manually append each test suite data in the template literal in a new line (i.e. if you add a new element to the accounts array you have to remember to add it in the template literal in a new line as ${accounts[2]}).