What is the difference between "test" and "spec" in automated testing?

Question

_{The question and doubts below address Node.js, Typescript and Javascript. I don’t know if the concepts below apply to other programming platforms/ languages.}

---

I am studying about automated tests (AT) using Jest and Typescript and I have come up with a question about the appointment of the test files. In some projects I have analyzed, some files are being named differently. Some have the nomenclature .test.ts and others .spec.ts. Until the present moment of the publication of this question, I had in mind that test or spec had no semantic difference, both served only to identify that that file is a test file, but the distinct file appointments gave rise to doubt on the subject.

Studying and researching on AT, I found good answers on the subject that helped me to understand a lot of the concept, but nothing that would clarify my doubt. For example, this excellent response from @utluiz where he talks about test concepts, I highlight 2 following points:

1. Unit Test: tests specific parts of the system, such as classes and methods.

2. Integration Testing: Tests multiple components of a system running at once.

Let’s keep that statement in mind.

Now we go from code to exemplify my doubt. In the test folder, I have 2 test files that basically what they do is to test the feature of registering a new administrator on the system. Now let’s go to the first file and I’ll still highlight the file name:

• The first is called admin-signup.test.ts and in this test file, he injects mocks of dependencies into the service module (AdminServices):

import * as AdminServices from '@naointeressa';

const adminData =  {...}

const AdminRepositoryMock =  {...}

const validatorMock =  {...}

const bcryptMockValidPass = {...}

describe('any', () => {
  it('should ...', async () => {
    const sut = await AdminServices.createAdminService(
      AdminRepositoryMock,
      validatorMock,
      bcryptMockValidPass
    )
    const newAdmin = await sut.createAdmin(adminData)

    expect(newAdmin.name).toBeDefined()
    expect(newAdmin.email).toBeDefined()
  })

  ...
})

• The second is called admin-signup.spec.ts and this differs from the previous because it does not inject mocks, but the true dependencies of the service module (AdminServices):

import * as AdminServices from '@naointeressa';
import * as AdminRepository from '@naointeressa';
import * as crypto from '@naointeressa';
import validator from '@naointeressa';

describe('any', () => {
  it('should ...', async () => {
    const sut = await AdminServices.createAdminService(
      AdminRepository,
      validator,
      cryptoObject,
    );
    const newAdmin = await sut.createAdmin(adminData);

    expect(newAdmin.name).toBeDefined();
    expect(newAdmin.email).toBeDefined();
  });
});

It was in this code (simplified obviously) that I had this doubt regarding the appointment of the test files.

I made an analysis of the above mentioned examples and came to the following thought:

• We use .test.ts when our test file does not test any external resources of our application (database, external API, HTTP calls, etc...), ie for tests that follow the quote 1 from the @utluiz response.

• We use .spec.ts when testing through the application’s external layers (other modules, libraries, databases, etc...), i.e., for citation 2 from the @utluiz response. Testing end-2-end would also have this kind of file nomenclature (quote Teste de Sistema in @utluiz’s reply, correct me if I’m wrong).

However I’m not sure of my conclusion above. I’m studying more about tests and I still have some questions, so, about my question of nomenclatures, I ask:

1. There are semantic differences between naming a file as .test.ts and .spec.ts?

2. If the answer to the above question is yes, is my thinking about where to use certain nomenclature correct? If not, and what context should I use either?

3. Or if there is no semantic difference between the names, I can adopt anyone, and they all have the same purpose... indicate that a file is a test file?

---

I used to think that spec comes from something specific, ie if the test tests a very simple and tiny application functionality like for example a function that checks if an email field is not empty ('') and only, nothing else. But it did not help me to heal the doubt. I would like a definitive answer.

Answer 1

There are semantic differences between naming a file as .test.ts and .spec.ts?

Not formally. Jest does not convene any kind of "suffix" in the file name. It ends up being a convention adopted by some groups of people to better organize their own suites testing.

Most people, I see, use only one suffix. How .test.js or .spec.js. It goes from the taste and the way the person writes the tests - as I said, there is no official rule.

It can be said that, written tests in format that most resemble a specification, use .spec.js be more "semantically correct". Go there.

---

If the answer to the above question is yes, is my thinking about where to use certain nomenclature correct? If not, and what context should I use either?

The answer to the previous question was nay - at the official level of Jest. However, developers of an organization may, for example, agree the use of .test.js for a thing and .spec.js to another.

In this case, a semantic differentiation is created, but it is limited to the entity that established it.

When this distinction is created, one can, for example, use:

• .spec.js for tests aimed at specifying some part of the code (such as documenting a Feature through code, for example). In this sense, it is most commonly used in the context of unit tests.

• .test.js for others. As more generic integration tests in which the goal is not to create a "code specification".

But overall it’s nothing greater that this, even because the name of the file little interferes in the functioning of the tests. The important thing, like much in programming, is to maintain consistency. In this sense, as the Jest not convencionada anything in relation to the nomenclature of the files, it is up to the developer to choose or create a convention and try to follow without many deviations.

---

Or if there is no semantic difference between the names, I can adopt anyone, and they all have the same purpose... indicate that a file is a test file?

Test is test. This is semantics. In the case of a significant difference between the functioning of the tests (such as integration or unity), can make semantic sense to change the "suffix convention" to reflect the established semantics. It goes from the programmer (or team - or whoever makes the decisions :P).

A suffix such as .test.js or .spec.js so that the test Runner can find the test files more easily, without having to analyze the file itself. From there the programmer can customize how the search will be done and customize the nomenclature.

In your case, you used .spec.js for integration and .test.js for unity. But make sure there are those who do the opposite (and it’s all right).

---

^{Note that I tried to be less assertive in this answer, since this topic is extremely subjective and highly fragmented (in the sense that it is very common to see several people using different conventions). Of course there are more common conventions, but they are still unofficial conventions.}