[일일 회고] 22.01.10.월 - 테스트 코드, 다 좋은 게 아니었어..

오늘은 특정 요구사항에 맞는 데이터 구조를 설계하고 구현했다.

테스트 코드에 집중하다 보니 객체 설계에 신경을 쓰지 못했고 도리어 나쁜 테스트 코드만 작성했다.

 

📚TIL

좋은 테스트 코드란 무엇일까?

단위 테스트 적용 3일 차, 테스트 코드는 다 좋은 게 아니었어... 😞

책, '단위 테스트 4장'에서 좋은 테스트를 작성하기 위해서는 4가지 특성을 잘 분배해야 한다고 한다. 회귀 방지를하고 리팩터링에 내성이 있으며 빠른 피드백이 가능하고 유지 보수하기 좋은 테스트 코드를 작성해야한다. 오늘은 ‘회귀 방지’를 못한 경험을 했다. 회귀 방지를 못한 것은 요구사항 추가, 수정 시 기능이 의도한 대로 작동하지 않는 경우다. 이점을 인지하지 못했다. 전에는 기능이 추가될 때마다 의도한 대로 작동하지 않으니 매번 테스트 코드를 수정하였다. 하지만 이런 일들의 반복의 원인은 나쁜 테스트 코드 때문이었다.

 

문제점 1. 간단한 코드 테스트

오늘 구현한 테스트 코드 커버리지는 100% 였다.! 처음엔 좋아 보였지만 이게 함정이었다. 예를 들어 너무나 간단한 기능을 가진 클래스나 메서드는 기능 구현의 기능이 커질수록 메서드의 이름이 바뀌거나 기능이 추가, 삭제 등 금방 변하게 되었다. 이전의 테스트는 더 이상 돌아가지 않았고 테스트 코드를 수정해야 했다.

✅ 기능 구현이 바뀔 때마다 테스트 코드가 바뀌는 것은 좋은 테스트 코드가 아닌 거 같다.

✅ 핵심 로직이 아닌 곳에 테스트 코드 작성에 시간을 들이는 것은 아깝지 않을까..?

✅ 눈으로 확인 가능한 클래스나 메서드는 굳이 테스트 코드가 필요할까..?

 

문제점 2. 외부 API 사용 테스트

외부 랜덤 메서드를 사용하는데 이를 테스트할 때 어떻게 검증해야 할까 감이 잡히지 않았다. 현재는 랜덤 값에 seed를 주어 기능 코드와 테스트 코드 모두 동일한 랜덤 값의 결과로 테스트했지만 이렇게 되면 기능 코드는 랜덤이 아니지 않은가?, 고민해봐야겠다. 분명 내가 작성하지 않은 코드에 대한 검증도 필요할 테니 말이다. 

✅ 외부 API를 테스트 범주에 포함시키자

 

깨달음

- 테스트 코드는 다 좋지 않다. 좋은 테스트를 구분하고, 작성해야한다.

- 핵심 로직에 테스트 코드를 작성하자.

- 구현 세부사항이 아닌 최종 결과 로직의 동작을 테스트하자

---

👍 Keep

• 새로운 프로젝트 단위 테스트 작성

🔥Problem

• 테스트 코드에 집중하다 보니 객체 설계에 대한 고민에 시간을 못씀
• 모든 메서드, 클래스에 테스트 코드를 작성하여 나쁜 테스트 코드 발생

🚒 Try

• 단위 테스트 포기하지 말자
• 나쁜 테스트 코드를 버리자
• 요구사항 분석 정확히 하자. 바로 기능 구현하지 말고 완벽하진 않겠지만 설계부터 고민해보자