단위 테스트

Unit Testing 유닛 테스트 과정 Fake UsersService를 만들어서 실행할 계획이다. 정상적으로 애플리케이션을 실행하면 DI 안에 많은 종속성을 넣어야 한다. 우린 새롭게 테스트를 위한 DI를 만드는데, 내부에는 Userss Service의 모든 메서드를 실행하는 클래스를 담는다. 이로서 어떤 단위(ex. Authentication, sign in 등)을 테스트하는데 종속성 주입에서 자유로워질 수 있다. Test 설정하기 users 디렉토리에 auth.service.spec.ts 파일을 만들자 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 // auth.service.spec.ts import { Test } from '@nestjs/testing'; import { AuthService } from './auth.service'; import { UsersService } from './users.service'; it('can create an instance of auth service', async () => { // 새 DI container 생성 // 하지만 AUthService를 위한 종속성을 제공하지 않았으니 실행하면 오류가 뜰것이다. constmudle = await Testing.createTestingModule({ providers:[AuthService] }).compile(); const service = module.get(AuthService); expect(service).toBeDefined(); }); 터미널에서 npm run test:watch를 입력한다. 3개가 failed라고 뜰텐데, p를 누르고 auth.service.spec 을 입력한다. 그럼 이 파일만 테스트하여 1 failed라고 뜬다. ...

2023년 10월 9일 · 5 분 · 배준수

Data 처리 및 저장

User Data Users service 이제 유저서비스를 다뤄보자. users.service.ts 파일을 수정하자 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 // users.service.ts import { Injectable } from '@nestjs/common'; import { Repository } from 'typeorm'; import { InjectRepository } from '@nestjs/typeorm'; import { User } from './user.entity'; @Injectable() export class UsersService { // repo : argument name // Repository<User> : User type을 다루는 Repository에 접근하여 instance를 받는다. // @InjtectRepository(User) : DI 시스템에게 우리가 User Repository가 필요하다는것을 말하는 코드 // DI 시스템은 뒤에 Repository<User>부분에서 inject할 인스턴스가 무엇인지 파악하기 위해 // type annotation 한다. generic에는 잘 작동 안하니까 앞에 decorator를 통해 더 분명히 제공한 것. constructor(@InjectRepository(User) private repo: Repository<User>) {} // create는 service 내에서 받은 정보(email과 password)로 User Entity Instance를 만든다. // save는 entity instance를 실제 Database에 저장해준다. create(email: string, password: string) { const user = this.repo.create({ email, password }); return this.repo.save(user); } } 이제 컨트롤러에 넣어보자 ...

2023년 10월 7일 · 9 분 · 배준수