24.06 - Why TDD(Test Driven Development)?

뭐든 겪어봐야 아는 건 만고불변의 진리

 

그래서 했다

 

TDD

 

마침, Global API를 express.js -> NestJS로 전환 개발하는 작업을

 

호기롭게 내가 하겠다! 라고 공표한 김에

 

바닥부터 쌓아가니, 좋은 건 다 때려 넣어! 의 정신으로

 

TDD를 도입 & 격주로 진행하는 팀 내부 개발 발표시간에 발표한 내용을 날 것 그대로 옮겨보았는데

 

극도로 부정적인 견해 & 그럼에도 긍정적인 견해가 섞여 있으니

 

읽음에 주의를 요합니다

 

---

 

Background

• Nest.JS로 전환하는 Global API 신규 개발 진행
  • “기왕” 하는 거 “굳이” 해 보며 장, 단점 파악하여 팀에게 전파

TDD를 직접 겪어보자

• TDD는 어떤 도구를 사용하면 좋을까?
  • Jest
    • Mocking, Spying 제공
    • Typescript 지원 → Babel 사용해야 함 → Jest 가 type 체크를 하지 않음
      • ts-jest 패키지로 타입체크 가능
    • 자료 풍부
    • 프로젝트가 클 경우 느릴 수 있음 & 설정이 복잡할 수 있음
  • Vitest
    
    • Mocking, Spying 제공
    • 빠름 & 설정 간단
  • Mocha
    • mocking, Spying 따로 해야 해서 불편
  • AVA
    • Promise 기반 테스트
    • Typescript type 체크 지원 가능
    • 속도 빠름
• 테스트는 어느 수준까지 작성해야 하는가?
  • 의도된 동작
  • 기상천외한 입출력 케이스… 는 끝이 없는데…?
• 현시점 결론
  • 안 해보곤 모르겠으니 셋 다 찍먹
    • Jest
    • Vitest
    • AVA

테스트가 좋은 이유?

• 테스트 코드를 작성하면서 어떻게 작동하는지 이해한다
  • 구현된 코드를 보며 이해하면 되잖아
• 소프트웨어를 수정할 때 예상치 못한 부작용을 방지한다
  • 그래서 예외처리를 꼼꼼하게 하는 거 아닌가
• 개발자 간의 협업을 원활하게 한다
  • 인정. 한 프로젝트를 십수 명이 만든다면
• 유지보수 하는데 필요한 문서화 작업을 줄인다
  • 문서부터 만들고 그런 말을 해볼까?

시도 내역

단위 테스트

• 정의 테스트
  • 함수, 메서드 등이 실제로 존재하는가
    • 이 짓을 내가 왜 하는가?
• 로직 테스트
  • CRUD 가 잘 동작하는가
    • Mock data를 만들어서 하는 테스트는 자기만족 아닌가?
    • 그럼 진짜 Entity를 기반으로 메서드를 호출하게 한다
      • 기능 테스트의 영역으로 넘어가버림
• 데이터 정합성 테스트
  • 신뢰성을 보장한다 → 로직 테스트랑 뭐가 다르지
  • 디비 테스트 툴을 사용한다
    • 쿼리 날려보는 게 더 빠르다
• 보안 테스트
  • 내부 사용만 하고 있으니까 굳이
• 통합 테스트
  • 기능 테스트
    • 실제 서버를 구동시켜 기능별 동작 확인 테스트
      • 실제 서비스 로직 구현해서 테스트하는 것과
      • 테스트 코드로 먼저 로직을 구현해서 테스트하는 것과 무슨 차이가 있을까
      • 심지어 테스트를 위해 모듈을 다 엮어서 테스트를 할 수 있도록 코드를 짜야한다
• 부하 테스트
  • k6를 통한 호출 테스트 → 현재 운영 중인 서버 호출량이 부하 테스트를 할 필요가 없는 수준 → k6 가 메인 코드에 들어가서 보기 싫어짐 → 부하 테스트는 별도 작업으로 분리하자

무엇에 대한 테스트였나

• Global API는 외부에 제공한다
  • 중요하다
    • 바코드, 영상, 캡처, 병원
  • 최소한 기능 테스트가 제공되면, 소통 비용이 감소한다
    • 이거 지금 되나요? → 테스트 돌려보세요
  • 최소한은 누가 정하는가
    • 결국 약속된 요청 → 응답 → 스펙에 맞는 데이터가 잘 조회되느냐 그뿐
• 부하 테스트는?
  • 할 필요가 없었다
  • 현재 스펙과 사용량으로는, 매우 안정적이다

그럼에도 좋은 점

• 안정성
  • 스키마 등이 변경되었을 때, 배포 전 테스트 단계에서 검증 가능
• 유지보수성
  • 내가 몰랐던 코드 변경사항 인지 가능
    • 다수가 같은 프로젝트를 개발한다면, 극대화되는 장점
  • 리팩토링 시 테스트 빠름

결론

Global API 기준

• TDD의 의도는 알겠으나, 현재 프로젝트에는 불필요
  • 십 수명이 공동작업 해야 하는 상황이 아님
  • 요구사항 변화가 없다시피 함
• 그럼에도 기본적인 단위 테스트는 있으면 좋다
  • 다수의 다른 프로젝트에서 호출이 잦다
  • 배포 전 테스트로 검증
  • 배포 후 이슈 특정 수월

= 상황에 맞춰 하자. 좋다고 아무 데나 다 갖다 붙이면 안 됨

 

 

---

 

테스트 라이브러리들이 왜 프런트엔드에서 시작되었는지 잘 알 수 있었다

 

테스트를 위한 테스트 작성이 의미 없다는 게 현시점의 결론이지만

 

이번 기회로 오히려 그동안 소홀했던 "진짜" 필요한 테스트를 작성하게 되었다

 

꼭 필요한 비즈니스 로직에 대한 테스트라든가

 

빌드 전 검증을 위한 테스트 등!

 

재밌었다