포시코딩

개요 오랜만에 Jest를 통해 테스트 코드를 작성하던 중 mockImplementation과 mockResolvedValue의 쓰임새에 대해 헷갈려 정리할 겸 포스팅 mockImplementation const mockResult = new Promise((resolve, reject) => { resolve({ message: '참여 성공' }); }); jest.spyOn(meetupsService, 'join').mockImplementation(() => mockResult); 모의 함수를 직접 구현할 때 사용한다. mockResolvedValue const mockResult = new Promise((resolve, reject) => { resolve({ message: '참여 성공' });..

오토 모킹 import { Test, TestingModule } from '@nestjs/testing'; import { ModuleMocker, MockFunctionMetadata } from 'jest-mock'; const moduleMocker = new ModuleMocker(global); // ModuleMocker는 getMetadata 메서드를 사용해 모듈의 메타데이터를 생성하고 // generateFromMetadata 메서드를 사용해 메타데이터를 바탕으로 모듈을 모킹한다. // 즉, 오토 모킹의 핵심 describe('ChatService', () => { let service: ChatService; // ChatService 인스턴스 let mockChatRepository:..

개요 오늘도 헛소리 하는 다른 블로그들이 답답해서 내가 해결방법 찾아 정리해본다. 기본 세팅 app.e2e-spec.ts import { Test, TestingModule } from '@nestjs/testing'; import { INestApplication } from '@nestjs/common'; import * as request from 'supertest'; import { AppModule } from './../src/app.module'; describe('AppController (e2e)', () => { let app: INestApplication; beforeEach(async () => { const moduleFixture: TestingModule = await Te..

개요 Controller - Service - Repository의 형태의 아키텍쳐로 이루어진 Nest.js 프로젝트에서 jest로 테스트 코드를 작성하려는데 아주 기본적인 틀만 가지고도 에러가 발생해 그 해결 과정에 대해 정리해보고자 한다. 일단 원래 보통 service에서 repository를 바로 inject 해오기 때문에 repository class가 따로 필요 없으나 여러 테이블을 join하거나 transaction을 쓰기에는 따로 구분 짓는 게 편하다고 생각해 custom repository를 만들게 되었다. 아래는 해당 repository의 코드다. Repository // ...import 생략 @Injectable() export class MeetupsRepository extends..

개요 테스트 코드를 작성하면서 의문이 들었던 부분이나 헤맸던 부분을 정리해봄 return이 avoid type인 메소드 users.repo createUser = async (userInfo) => { await this.usersModel.create({ email: userInfo.email, password: userInfo.password, // ...생략 }); }; unit test code test('users.repository createUser Method success', async () => { mockUsersModel.create = jest.fn(() => { return 'test'; }); const userInfo = { email: 'test@gmail.com', pas..

테스트 코드란? 테스트 코드는 말 그대로 작성한 코드에 문제가 없는지 테스트하기 위해 작성하는 코드이다. 흔히 테스트 기본 원칙이라고 불리는 '일곱 테스트 원칙'은 다음과 같다. 테스팅은 결함이 없는 것이 아니라, 결함의 존재를 보여주는 것이다. 완벽한 테스트는 불가능하다. 테스트 구성은 가능한 빠른 시기에 시작한다. 결함은 군집되어 있다.(결함의 80%는 20%의 코드로 인해 발생한다.) Pesticide paradox(살충제 역설) - 비슷한 테스트가 반복되면 새로운 결함을 발견할 수 없다. 테스트는 정황에 의존적이다.(상황에 따라 다르다.) 오류 부재의 오해 - 사용되지 않는 시스템이나 사용자의 기대에 부응하지 않는 기능의 결함을 찾고 수정하는 것은 의미가 없다. https://www.boxuk.c..