13일차 회의록 (11월 09일)

• BE만 진행

Agenda

1. 예외 계층 통일
2. 테스트 코드 작성
3. 협업 규칙: 스케줄 공유
4. dto 공유
5. 서비스 계층의 의존성

예외 계층 통일

NestJS, 효과적인 예외 핸들링

Documentation | NestJS - A progressive Node.js framework

1. 커스텀 에러를 만들어서 사용하자
2. exception filter를 만들어서 비즈니스 로직의 try, catch문 제거

• custom exception을 어디에 둘 것인가

  • src 밑에 전역으로 두기

• custom exception을 어떻게 작성할 것인가

  클래스 명은 어떤 에러인지 명확하게 표현되도록 작성하고 (엔티티 이름 + 예외 상황 + Exception)
  클래스 내부에서 에러 메시지 까지 정의
  

서비스 계층 의존성

• 서비스끼리 의존하도록 만들기

  • 비교적 복잡한 로직 캡슐화 가능 → 유저의 최근 로그인 시간을 가져온다던가
    • userRepository.findOneBy ... vs. userService.getUserRecentlyLoggedIn
  • 중복 로직을 줄일 수 있다.

• 서비스끼리 의존하지 않게 하기

  • 레포지토리만 의존하고, 서비스 계층에서 상세 로직 작성
  • 중복 로직이 생겨 코드가 많아질 것 → 코드 관리 측면에서 효율적이지 않을수도?

테스트 코드 작성

단위 테스트

• nest-cli에서 제공해주는 기본 템플릿 수정해서 사용하기
• 컨트롤러 / 서비스 계층은 의존성이 있는 계층을 모두 모킹하여 동작 확인이 가능하도록 작성
  • 성공 케이스 + 예외 케이스 모두 1개 이상 작성한다.
  • 어떤 테스트케이스인지 한글로 표현할 것
• 레포지토리는 인메모리db를 활용하여 테스트
  • 모킹 대신 생성자 코드 수정 필요
  • 직접 작성한 메서드 & 래핑한 메서드에 대해 동작 테스트 작성 (TypeORM에서 제공해주는 메서드 자체에 대한 테스트 제외)

통합 테스트

• supertest 라이브러리를 사용해서 통합 테스트를 수행한다.
• 통합 테스트 코드 위치는 모듈 안에 둔다.

테스트 네이밍 컨벤션

• describe에는 테스트 하고자 하는 클래스 이름을 작성한다.
• it에는 코드를 읽지 않아도 뭔지 알 정도로 설명을 상세하게 작성한다.

  • 어떤 행동 + 성공/실패 - 어떤 테스트 케이스인지 설명

    ex)

    엣지 생성 성공

    엣지 생성 실패 - 만약 유저 권한이 없으면 실패한다.

DTO 공유

• 모듈 내에 dto 폴더를 만들어 두고, 각 클래스마다 따로 작성한다.

• dto 이름.dto.ts 로 작성

• DTO 설명을 JSDOC으로 작성

• NX, Turbo와 같은 도구를 사용하면 쉽게 공유할 수 있는 것 같다.

• 프로젝트 루트에 shared를 두면, FE에서 참조할 수 있나요?

협업 규칙

• 서로 뭘 하고있는지 잘 모르겠어요

  1. 월요일 → [BE, FE] 금요일에 데모에 뭘 보여줄지 정하기

  2. 월요일 → [BE] 일주일치 작업량을 정해두기

  3.        → 각자 일 분배하기 + 서로 먼저 끝난 사람이 다른 사람 도와줄 수 있음
     

  4.        → 데일리스크럼때 노션에다가 (a) 오늘 작업하는 시간 (b) 작업할 테스크 다 적어놓기
     

  5. 실시간으로 지금 무슨 작업을 하고 있는지 아는 방법

     1. 게더타운?
     2. 슬랙?

     → 완전 실시간일 필요는 없을 수도?

     그냥 게더타운에 계속 있다가 필요할 때 말걸기

• DTO, Custom Exception, 서비스 의존성, 테스트 코드 → 페어로?