TDD는 실제 코딩하는 시간보다 이를 먼저 설계하고 준비하는 단계에 투자하는 시간이 더 많아야한다는 말이 있다. 그만큼 내가 지금 만들려고하는 것이 무엇인지 그 목적을 명확히하고 어떻게 테스트할 것인지 구체적인 케이스들을 정리하는 것이 중요한 작업이다.
여기서는 배달서비스에서 회원가입이라는 기능을 가볍게 구현하기 위해 앞선 장에서 살펴본 방법론에 따라 테스트 케이스들을 만들어보기로 한다.
1. 요구사항
먼저, 회원가입에 대해 다음의 두 가지 요구사항이 있다.
- 사용자 회원가입이 필요하다
- 매장 사장님 회원가입이 필요하다
2. 테스트 시나리오
두 가지 종류의 회원 가입이 있기 때문에 일반 사용자가 접근하는 회원가입 페이지와, 매장 사장님이 접근하는 회원 가입 페이지가 다를 것이다.
또, 보통 매장사장님 같은 유형의 기업/사업자 회원은 회원가입시 사업자등록증 검사 등의 작업이 함께 이루어지는데, 이번 프로젝트에서는 한명의 사업자가 여러 매장을 운영할 수 있다는 설정이 팀 내부적으로 설정되었다. 따라서, 일반 사용자와 매장 사장님 회원가입에 요구되는 정보가 유사해졌고, 이 둘을 구분하는 정도의 로직만 들어갈 수 있으면 된다.
이를 통해 유저들의 use case들을 예상해보면,
- 일반 사용자와 매장 사장님을 위한 회원가입 페이지가 따로 있다.
- 회원가입에 필요한 정보를 입력한다.(email, name, password)
- 올바르지 않은 형태의 이메일, 이미 가입된 정보의 이메일 등이 입력될 수 있다.
- 보안이 약한 위해 지나치게 짧은 길이의 비밀번호를 입력할 수 있다.
- 예상치 못한 버퍼오버플로우 등의 보안 문제를 일으키기 위해 지나치게 긴 비밀번호 길이를 입력할 수 있다.
- 회원가입 요청을 보낸다.
3. 테스트 케이스 구체화
이제 작성한 시나리오를 검증할 수 있는 테스트 케이스들을 세분화할 수 있는데까지 파고 들어가야한다.
- 일반 사용자와 매장 사장님을 위한 회원가입 페이지가 따로 있다.
회원가입 하려는 사용자의 유형을 확인할 수 있는 수단이 필요하다.
- 회원가입에 필요한 정보를 입력한다.(email, name, password)
- 올바르지 않은 형태의 이메일, 이미 가입된 정보의 이메일 등이 입력될 수 있다.
- 보안이 약한 위해 지나치게 짧은 길이의 비밀번호를 입력할 수 있다.
- 예상치 못한 버퍼오버플로우 등의 보안 문제를 일으키기 위해 지나치게 긴 비밀번호 길이를 입력할 수 있다.
회원가입폼에 입력한 데이터들은 필요한 데이터들이 제대로 보내졌는지 유효성 검사가 필요하며, 서비스 내부적인 정책에서 정한 형식이나 길이를 초과하지는 않았는지 세부적으로 확인한다.
- 회원가입 요청을 보낸다.
회원가입을 보내면 데이터를 생성해야하는데, 비밀번호를 평문인채로 저장할 수는 없다. 따라서, 암호화 과정을 거치고 이를 검증하며, 마찬가지로 회원 데이터가 정상적으로 생성되었는지도 확인을 해야한다.
이를 조금 더 보기 좋은 형태로 정리하면 좋은데, 정리 방식에는 굉장히 다양한 예시가 있다. 그리고 이 형태는 개인마다 혹은 팀마다 나름의 이유와 컨밴션이 있기 때문에 정답은 없다. 따라서 아래의 이미지는 굉장히 다양한 예시들 중 하나일 뿐이며, 충분히 다양한 사례들을 검토해보고 현재 팀에 맞거나 필요한 형태를 갖추고 필요한 정보들을 기입한다.
위 테스트 케이스를 짤 때는 다음의 3가지를 고려하였다.
1. 비록 TDD가 bottom-to-top을 지향하지만, 역할분담의 편의성과 시나리오를 준수하고 있는지 쉽게 확인하기 위해 도메인에서부터 최소 단위 테스트까지 그 분기를 기록
2. 해당 테스트 케이스가 로직의 성공과 실패 어느 상황을 테스트하는지 표시
3. 테스트 케이스 테이블만 보고 바로 테스트 코드를 작성할 수 있는 형태로 기록
4. 테스트 준비
이제 작성한 시나리오를 바탕으로 서비스를 구현하기 위한 Users 모듈을 생성하자.
TDD % nest g res users
? What transport layer do you use? REST API
? Would you like to generate CRUD entry points? No
CREATE src/users/users.controller.spec.ts (566 bytes)
CREATE src/users/users.controller.ts (210 bytes)
CREATE src/users/users.module.ts (247 bytes)
CREATE src/users/users.service.spec.ts (453 bytes)
CREATE src/users/users.service.ts (89 bytes)
UPDATE src/app.module.ts (256 bytes)📦
├─ src
│ ├─ users
│ │ ├─ users.controller.spec.ts
│ │ ├─ users.controller.ts
│ │ ├─ users.module.ts
│ │ ├─ users.service.spec.ts
│ │ └─ users.service.ts
│ ├─ app.module.ts
│ └─ main.ts
├─ test
│ ├─ app.e2e-spec.ts
│ └─ jest-e2e.json
└─ package.json위와 같이 users 모듈과 하위 파일들이 생성되었다. 이제 다음 장부터 본격적으로 TDD 개발을 시작해보겠다.
