670

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 difference between them?

describe('updateAll', () => {
  it('no force', () => {
    return updateAll(TableName, ["fileName"], {compandId: "test"})
        .then(updatedItems => {
          let undefinedCount = 0;
          for (let item of updatedItems) {
            undefinedCount += item === undefined ? 1 : 0;
          }
          // console.log("result", result);
          expect(undefinedCount).toBe(updatedItems.length);
        })
  });

  test('force update', () => {
    return updateAll(TableName, ["fileName"], {compandId: "test"}, true)
        .then(updatedItems => {
          let undefinedCount = 0;
          for (let item of updatedItems) {
            undefinedCount += item === undefined ? 1 : 0;
          }
          // console.log("result", result);
          expect(undefinedCount).toBe(0);
        })
  });
});

Update - Nov 2022:

It seems that test and it is interchangeable according to the official API of Jest. As @gwildu described here, you should choose one over the other for the sake of readability.

C.Lee
  • 10,451
  • 9
  • 31
  • 46

10 Answers10

873

The Jest docs state it is an alias of test. So they are exactly the same from a functional point of view. They exist both to enable to make a readable English sentence from your test.

musicformellons
  • 12,283
  • 4
  • 51
  • 86
244

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
gwildu
  • 3,621
  • 1
  • 17
  • 22
  • 15
    some also prefer `it('does this thing', () => {})` instead of `it('should do this thing', () => {}` as its shorter – gwildu Dec 24 '19 at 15:01
  • Alternatively, `test('thing should do x')` may be preferred over `it('Should do X')` as `it` is often vague. – mikemaccana Mar 06 '20 at 16:31
  • 1
    @mikemaccana if you write `test('thing should do x')` you don't have a semantically correct sentence. The Idea behind those notation I think is really, that you can read a test in a sentence as you would speak. Same if you write `test('Does this thing')`. Of course you can do that, but the notation semantically would actually fit to the `it` notation – gwildu Nov 10 '20 at 07:32
  • 2
    `test('thing should do x')` is literally 'testing that thing should do X' - so the test reads as one would speak. `test('thing does x')` is also fine. – mikemaccana Nov 10 '20 at 14:43
46

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:

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rich
  • 15,048
  • 2
  • 66
  • 119
12

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.

SeyyedKhandon
  • 5,197
  • 8
  • 37
  • 68
9

You could replace it() with xit() to temporarily exclude a test from being executed; using it() and xit() is more eloquent than using test() and xit().

see Focusing and Excluding Tests

Adrian
  • 3,321
  • 2
  • 29
  • 46
4

The following is an excerpt from the document:link

test(name, fn, timeout)

Also under the alias: it(name, fn, timeout)

All you need in a test file is the test method which runs a test. For example, let's say there's a function inchesOfRain() that should be zero. Your whole test could be: ......

Luca Kiebel
  • 9,790
  • 7
  • 29
  • 44
biao tong
  • 49
  • 2
-4

const request = require('supertest'); const app = require('../app') const {it, describe} = require('@jest/globals'); const { sequelize } = require('../models'); const {hash} = require('../helpers/bcrypt')

beforeAll(async ()=>{ await sequelize.queryInterface.bulkInsert('Customers', [{ username: "nikita", email:"nikita@mail.com", password: hash("nikita"), createdAt: new Date(), updatedAt: new Date() }]) })

afterAll(async ()=>{ await sequelize.queryInterface.bulkDelete('Customers', null, { truncate: true, cascade: true, restartIdentity: true }) })

describe('POST /customers/register', () => { it('should response with status 201', async ()=> { let customer = { username: "hello" , email:"hello@mail.com", password:"hello", } let response = await request(app) .post('/customers/register').send(customer) expect(response.status).toBe(201) // console.log(response.body, 'ini ressss') expect(response.body).toEqual({ message: "Input data Customer succeed", id: expect.any(Number), email: expect.any(String) }) }); it('should response with status 400', async()=>{ let customer = { username: "hello", password:"hello" } let response = await request(app) .post('/customers/register').send(customer) expect(response.status).toBe(400) // console.log(response.body,"<<<"); expect(response.body[0].message).toBe('Please input email') })

Madkday
  • 1
  • 1
  • 1
    As it’s currently written, your answer is unclear. Please [edit] to add additional details that will help others understand how this addresses the question asked. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 07 '23 at 22:44
-4
`const request = require('supertest');`
`const app =  require('../app')`
`const {it, describe} = require('@jest/globals');`
`const { sequelize, Category, User, News , Customer, Bookmark} = require('../models');`
`const {hash} = require('../helpers/bcrypt');`
`const news = require('../models/news');`
`const {queryInterface} = sequelize`


`beforeAll(async()=>{

    let userData = require("../data/user.json")
    userData.forEach(el => {
        el.password = hash(el.password)
        el.createdAt = new Date()
        el.updatedAt = new Date()
    });`

`afterAll(async ()=>{
    await Bookmark.destroy({
        truncate: true,
        cascade: true,
        restartIdentity: true
    })`

`describe('GET /customers/news', () => {
    it("should response with status 200 1", async () => {
        let response = await request(app)
        .get('/customers/news')
        // .set({access_token})
        // console.log(response.body, "<<<<NEWS NIhH");
        expect(response.status).toBe(200)
        expect(response.body).toBeInstanceOf(Array)
    })`

`it("should response with status 200 2", async()=>{
    let response = await request(app)
    .get('/customers/news?filter=1,2')
    expect(response.status).toBe(200)
    expect(response.body).toBeInstanceOf(Array)
})`
Madkday
  • 1
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – Community Feb 08 '23 at 13:27
-19

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.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
kishor borate
  • 158
  • 1
  • 11
-36

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;
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
杨正云
  • 37
  • 1
  • 2
  • 40
    The code you show does not indicate that `it` and `test` are the same thing. It just means that their type is the same. I do not think that `beforeAll` and `afterAll` are the same thing even though their type is the same. – realUser404 Apr 16 '18 at 20:56
  • 6
    `xit and xtest` skips the tests, `it, fit, test` are to execute tests. Thanks for your answer. – Aakash Nov 17 '19 at 05:54