Задать вопрос
@mikilikala
На фронте

Как лучше всего писать тесты e2e для бэкэнда NestJS?

`import { Test, TestingModule } from '@nestjs/testing'
import { INestApplication, ValidationPipe } from '@nestjs/common'
import request from 'supertest'
import { AppModule } from '../src/app.module'
import {DataSource} from "typeorm";

describe('Auth (e2e)', () => {
    let app: INestApplication
    let dataSource: DataSource
    const testEmail = `test_${Date.now()}@test.com`
    const testPassword = 'TestPassword123'

    beforeAll(async () => {
        const moduleFixture: TestingModule = await Test.createTestingModule({
            imports: [AppModule],
        }).compile()

        app = moduleFixture.createNestApplication()
        app.useGlobalPipes(new ValidationPipe())
        await app.init()

        dataSource = app.get(DataSource)
    })

    afterAll(async () => {
        await dataSource.query(`DELETE FROM "user" WHERE email LIKE 'test_%'`)
        await app.close()
    })

    it('POST /auth/register - should register new user', () => {
        return request(app.getHttpServer())
            .post('/auth/register')
            .send({ email: testEmail, password: testPassword })
            .expect(201)
            .expect(res => {
                expect(res.body.email).toBe(testEmail)
                expect(res.body.id).toBeDefined()
                expect(res.body.password).toBeUndefined()
            })
    })

    it('POST /auth/register - fail if email is not email', () => {
        return request(app.getHttpServer())
            .post('/auth/register')
            .send({ email: "notemail", password: testPassword })
            .expect(400)
            .expect(res => {
                expect(res.body.message).toStrictEqual(["email must be an email"])
                expect(res.body.error).toBe("Bad Request")
                expect(res.body.statusCode).toBe(400)
            })
    })

    it('POST /auth/login - should login new user', () => {
        return request(app.getHttpServer())
            .post('/auth/login')
            .send({ email: testEmail, password: testPassword })
            .expect(201)
            .expect(res => {
                expect(res.body.success).toBe(true)
            })
    })

    it('POST /auth/register - should fail if email already exists', () => {
        return request(app.getHttpServer())
            .post('/auth/register')
            .send({ email: testEmail, password: testPassword })
            .expect(400)
            .expect(res => {
                expect(res.body.message).toBe("Email already exists")
                expect(res.body.error).toBe("Bad Request")
                expect(res.body.statusCode).toBe(400)
            })
    })
})


У меня есть файл с тестами для /auth/. Правильно ли я делаю, когда пишу столько тестов?:
- fail if email is not email
- should login new user
- should fail if email already exists
То есть, должен ли я писать e2e тесты абсолютно на все, что может вернуть бэкенд?

Также, если у вас есть репозиторий, в котором вы писали e2e тесты и unit тесты, я был бы очень благодарен, если бы вы поделились им со мной.
  • Вопрос задан
  • 57 просмотров
Подписаться 1 Простой 1 комментарий
Решения вопроса 1
opium
@opium
Просто люблю качественно работать
Нет, тестировать всё подряд в e2e не нужно — для этого есть unit-тесты. На e2e уровне достаточно основных флоу: успешная регистрация, успешный логин, и пару критических ошибок (дубль, невалидный формат). Валидацию всех полей (длины, регексы, типы) лучше покрывать unit-тестами — там это дешевле и не поднимает весь AppModule.
Ответ написан
Пригласить эксперта
Ответы на вопрос 1
Рассматривай e2e тесты в контексте всего проекта (подумай о тестировщиках-людях и о том, как заказчик потом будет принимать работу) и подумай о том, какую вообще проблему они решают.

В конечном итоге ты стремишься к вот такой ситуции:
1. Все бизнес-сценарии, которые описаны в спецификации реализованы именно так, как они описаны в спецификации.
2. То что не описано в спецификации - не приводит к угрозам безопасности или неисправимым ошибкам.

Обрати внимание, что тут ни слова о nest и всём что может вернуть бэкенд нет.

1. Чем меньше денег компания на это потратит, тем лучше.
2. Затраты на тестирование соразмерны вохможным убыткам от ошибок, которые можно было бы пропустить.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы