Процесс тестирования с TypeORM и Nestjs, и Jest с использованием макетов? - PullRequest
0 голосов
/ 14 октября 2018

Этот вопрос, вероятно, может быть обобщен на заглушки репозиториев в сервисе и на то, как правильно протестировать и обеспечить охват в контексте этого вопроса.

Я нахожусь в процессе обученияо тестировании, но я застрял в том, как правильно выполнять тестирование, которое включает в себя БД.

У меня есть объект User, который определяет столбцы и некоторую начальную логику проверки.

    import { IsAlphanumeric, IsEmail, MinLength } from 'class-validator';
    import { Column, Entity, PrimaryGeneratedColumn } from 'typeorm';
    @Entity()
    export class User {
      @PrimaryGeneratedColumn()
      public id!: number;

      @Column()
      public name!: string;

      @IsEmail()
      @Column()
      public email!: string;

      @MinLength(8)
      @Column()
      public password!: string;
    }

И у меня есть UserService, который внедряет репозиторий для объекта.

    import { Injectable } from '@nestjs/common';
    import { InjectRepository } from '@nestjs/typeorm';
    import { validateOrReject } from 'class-validator';
    import { Repository } from 'typeorm';
    import { CreateUserDTO } from './dto/create-user.dto';
    import { User } from './user.entity';

    @Injectable()
    export class UserService {
      constructor(
        @InjectRepository(User) private readonly userRepository: Repository<User>
      ) {}

      public async create(dto: CreateUserDTO) {
        const user = this.userRepository.create(dto);
        await validateOrReject(user);
        await this.userRepository.save(user);
      }

      public async findAll(): Promise<User[]> {
        return await this.userRepository.find();
      }

      public async findByEmail(email: string): Promise<User | undefined> {
        return await this.userRepository.findOne({
          where: {
            email,
          },
        });
      }
    }

И вот мой предварительный тест, чтобы вы могли следовать моим ходом мыслей ...

    import { Test, TestingModule } from '@nestjs/testing';
    import { getRepositoryToken } from '@nestjs/typeorm';
    import { User } from './user.entity';
    import { UserService } from './user.service';

    const createMock = jest.fn((dto: any) => {
      return dto;
    });

    const saveMock = jest.fn((dto: any) => {
      return dto;
    });

    const MockRepository = jest.fn().mockImplementation(() => {
      return {
        create: createMock,
        save: saveMock,
      };
    });
    const mockRepository = new MockRepository();

    describe('UserService', () => {
      let service: UserService;

      beforeAll(async () => {
        const module: TestingModule = await Test.createTestingModule({
          providers: [
            UserService,
            {
              provide: getRepositoryToken(User),
              useValue: mockRepository,
            },
          ],
        }).compile();
        service = module.get<UserService>(UserService);
      });

      it('should be defined', () => {
        expect(service).toBeDefined();
      });

      it('should not create invalid user', async () => {
        // ??
      });
    });

Так что, хотя я могу сделать тестовый прогон и все остальное, я не уверен, каким я на самом деле должен бытьтестирование.Очевидно, я могу проверить, что он проверяется при создании, и для других вещей, таких как findAll, я чувствую, что просто издеваюсь с базой данных?Для того, чтобы я правильно проверил это, нужно ли его подключить к базе данных, чтобы я мог проверить, возвращаются ли нужные данные?

В документах Nest говорится: «Обычно мы хотим избежать какого-либо соединения с базой данных», но это не так.Разве это не противоречит цели, поскольку мы не действительно тестируем функциональность?Потому что, хотя я могу посмеяться над тем, что сохранение возвращает значение, я не проверяю наличие ошибок, которые могут возникнуть с уникальными столбцами, обнуляемыми данными, инкрементными значениями, которые нужно установить, и т. Д. ... верно?

1 Ответ

0 голосов
/ 18 октября 2018

Многие считают плохой практикой тестирование против БД.Но именно по тем причинам, о которых вы упомянули, + избавляя себя от хлопот управления макетами и заглушками, я почти всегда запускаю свои тесты на выделенной базе данных тестов.

При запуске в шутку я очищаю все таблицы, а затем имею помощников, которые помогают мне создавать сущности с необходимыми отношениями, чтобы мой тест оставался атомарным.

...