어느덧 회사에서 내가 작성한 테스트 코드가 310개를 돌파했다.
테스트 커버리지나 테스트 코드 개수가 많다고 무조건 좋은게 아니다 라는 사실을 모르고 이런 말을 하는 것은 아니다.
단지 뭐든지 처음엔 양치기라 생각한다.
많은 양의 작업을 처리하는 과정에서 나만의 프로세스나 철학을 세우고 싶다. (TDD는 개인적으로 연습하고 있다.) 아무튼 현재 나는 테스트 코드의 작성 완료까지를 개발의 완료로 정의하고 있다.
여러 시행착오를 겪으며 얻은 경험을 한번 정리해보고 싶었다.
1. 유스케이스를 먼저 작성해야겠다
테스트 코드 작성하기 전, 무엇을 검증할지 명확히 하는 것은 매우 중요하다.
- 1) 테스트 코드 자체가 명확하고 간결해져 코드 길이가 짧아진다.
- assert 문 역시 간단명료하다
- 테스트 코드 내 변수 이름에 검증하려는 의도를 입힐 수 있다.
- 2) 테스트 코드의 가독성이 향상된다.
- 테스트 코드 함수만 읽어도 의도를 단번에 파악할 수 있다.
- 테스트 코드는 비즈니스 로직이 아니다. 함수명을 어려운 영어로 표현하기보다 한글로 표현하면 다른 동료 개발자들이 이해하기가 명확해진다.
- 3) QA 관점에서 비즈니스 로직을 다시 바라보게 해준다.
- 테스트 하려는 요소가 명확해지면서, 로직에 불필요한 것들이 있음을 알려준다. 테스트 코드 작성을 하며 부분적으로 리팩터링을 진행하게 되는 이점이 있다.
2. 유닛 테스트는 다다익선이구나
백엔드 개발자로써
작성할 수 있는 테스트 코드는 유닛 테스트와 통합 테스트다.
(UI 테스트(인수 테스트)는 배포 과정 직전에)
현재 회사의 결제 모듈 역시 통합 테스트보다 유닛테스트가 더 많다.
처음부터 이랬던 건 아니다.
API 호출 흐름이나 결제 FLOW를 고려한 통합 테스트 작성에 더 많은 시간을 들였었다. 그래야 불안하지 않았다.
하지만, 수많은 리팩터링을 겪으며 느낀 바는 이렇다.
현재의 방식으로는
1) 변동성/유동성이 핵심인 비즈니스 로직에 알맞지 않다.
2) 테스트 코드 회귀(regression)에 기민하게 대응할 수 없다.
따라서, 모든 결제 FLOW를 고려한 통합 테스트를 작성할 필요는 없다.
다만, 결제 구현에 사용된 클래스, 함수 단위의 기능들은
모두 유닛 테스트로 1000000% 검증돼야 한다.
한마디로 요약하자면, "통합테스트보다 유닛테스트에 더 집중하자"3. 비즈니스 코드 외의 변수들을 조심해야겠다
1) 데이터베이스 환경
로컬 환경에서는 문제없이 작동하던 queryset이
운영 환경에서 문제가 생기는 경우가 발생했다.
현재 원인을 분석중이다.
annotate부분이 문제였는데, 운영환경에서는 Cast로 직접적으로 명시하지 않는 이상 날짜 정보를 str로 형변환 시켜버렸다.
로컬에서의 UI테스트와 유닛테스트에서는 검출되지 않은 에러였다.
2) 몽키 패치로 검증하지 않은 알림/메시지 발송 기능
테스트 코드에서 thrid party의 검증을 하지 않는다.
카카오 메시지를 발송하거나 슬랙 메시지를 보내는 기능은 성공했다 가정하고
비즈니스 로직을 검증한다. 그러므로 운영환경에서 메시지가 제대로 전송될지 100% 확신하는 게 어렵다.
그러면 어떻게 해야할까
변수를 최소화해야 한다.
메시지가 발송되지 않는다면 그건 순전히 requests의 get 또는 post 요청 에러여야만 한다.
즉, 설계를 잘해야 한다.
1️⃣ 비동기적으로 발송될 메시지는 요청하는 책임만 지니게 함수를 작성해야 한다.
2️⃣ 발송 조건 로직, 상태 검증과 같은 작업들은 다른 함수에게 책임을 위임한다. 우리는 이렇게 발송을 제외한 작업들을 하는 함수들을 철저히 단위 테스트하면 된다.
4. 테스트 코드도 진화하는구나
소프트웨어의 변동이 불가피함을 인정하는 것이 매우 기본이자 중요한 특성이라고 한다.
최근에도 비즈니스 로직 변경 요청이 있었다.
코드를 수정하니, 일부는 테스트 코드가 FAIL이 됐지만, 몇 개는 예상과 달리 실패하지 않았다.
"아, 내가 작성한 테스트 코드에 이런 맹점이 있었구나"하고 느낀 순간이었다.
이럴 때마다 내가 놓쳤던 부분에 대한 테스트 코드를 다시 리팩터링했다.
비즈니스 코드 뿐만 아니라 테스트 코드도 변한다.
