I have two tests in my test group. One of the tests use it
and the other one uses test
. Both of them seem to be working very similarly. What is the dif
They are the same thing. I am using TypeScript as the programming language, and when I look into the definition file from the Jest package source code from /@types/jest/index.d.ts, I can see the following code.
Obviously, there are lots of different names of 'test', and you can use any of them.
declare var beforeAll: jest.Lifecycle;
declare var beforeEach: jest.Lifecycle;
declare var afterAll: jest.Lifecycle;
declare var afterEach: jest.Lifecycle;
declare var describe: jest.Describe;
declare var fdescribe: jest.Describe;
declare var xdescribe: jest.Describe;
declare var it: jest.It;
declare var fit: jest.It;
declare var xit: jest.It;
declare var test: jest.It;
declare var xtest: jest.It;
The Jest docs state it is an alias of test. So they are exactly the same.
As the jest documentation says, they are the same: it alias
test(name, fn, timeout)
Also under the alias: it(name, fn, timeout)
And describe
is just for when you prefer your tests to be organized into groups:
describe
describe(name, fn)
describe(name, fn)
creates a block that groups together several related tests. For example, if you have a myBeverage object that is supposed to be delicious but not sour, you could test it with:
const myBeverage = {
delicious: true,
sour: false,
};
describe('my beverage', () => {
test('is delicious', () => {
expect(myBeverage.delicious).toBeTruthy();
});
test('is not sour', () => {
expect(myBeverage.sour).toBeFalsy();
});
});
This isn't required - you can write the test blocks directly at the top level. But this can be handy if you prefer your tests to be organized into groups.
Jest haven't mentioned why they have two versions for the exact same functionality.
My guess is, it's only for convention. test
is for unit tests, and it
is for integration tests.
As the other answers have clarified, they do the same thing.
I believe the two are offered to allow for either 1) "RSpec" style tests like:
const myBeverage = {
delicious: true,
sour: false,
};
describe('my beverage', () => {
it('is delicious', () => {
expect(myBeverage.delicious).toBeTruthy();
});
it('is not sour', () => {
expect(myBeverage.sour).toBeFalsy();
});
});
or 2) "xUnit" style tests like:
function sum(a, b) {
return a + b;
}
test('sum adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
Documentation:
They do the same thing, but their names are different and with that their interaction with the name of the test.
test
What you write:
describe('yourModule', () => {
test('if it does this thing', () => {});
test('if it does the other thing', () => {});
});
What you get if something fails:
yourModule > if it does this thing
it
What you write:
describe('yourModule', () => {
it('should do this thing', () => {});
it('should do the other thing', () => {});
});
What you get if something fails:
yourModule > should do this thing
So it's about readability not about functionality.
In my opinion, it
really has a point when it comes to read the result of a failing test that you haven't written yourself. It helps to faster understand what the test is about.
Some developer also shorten the Should do this thing
to Does this thing
which is a bit shorter and also fits semantically to the it
notation.