Relaxed Conventions

Test suites conventions

If you’re coming from different test runners or frameworks, you’ll know that they differ in their test suites syntax.

different syntax across frameworks or their versions to write tests

Some use describe.only(), in others you can only have test().

In some of them you disable a test by test.skip() while in others it’s xit().

With Jest, it doesn’t matter.

It does its best to optimize productivity instead of strict conventions.

You can write test(), or a nested describe() and test(), or just use it().

No brainer.

It Just Works!

Which file naming convention should you use for tests?

Who cares! 😜

Jest will automatically pick up any *.test.js or *.spec.js file extensions, as well as any files in a __tests__ directory.

Friendly CLI

Jest has a friendly CLI that will help you figure out what you mean incase of spaghetti fingers:

Jest recommending correct commands

Sure, it’s not a time travel but it’s another corner stone in Jest’s productivity boosting and developer friendliness.

It’s the little things that matter the most.

Test Doubles

In automated testing, where we write and execute unit and integration tests, it is a common practice to make use of different kinds of test doubles to isolate different parts of the system.

There are different methods of isolation with different goals and behaviors, but they are all collectively referred to as test doubles.

Where as other libraries like Sinon require you to explicitly declare and choose a type of a test double for your test (a stub, a mock, a spy), Jest wraps everything into a single entry point called the Mock object (jest.fn).

The Mock is accessed and used in different ways through the test code, still essentially you don’t need to bother yourself with such decisions in your test code about types of test doubles. It’s another productivity gain with Jest.

That said, you should still understand testing principles.