1/15 TIL 단위 테스트 안티패턴

비공개 메서드

원칙적으로 테스트하면 안된다.

커버리지가 부족하다면

죽은 코드거나,
추상화가 누락된 것이다. -> 다른 클래스로 분리해 공개메서드로 빼자

테스트해도 되는 경우

식별할 수 있는 동작이면 테스트해도 된다.
예를 들면 ORM의 비공개 생성자 같은 경우

비공개 상태

테스트를 위해 노출시키지 말자
노출 안된 이유가 있을 것이다. 비공가 상태가 아닌 다른 메서드를 이용해 최종 상태를 체크하자.

도메인 지식 유출

테스트하려는 코드의 로직을 그대로 구현하지 말자.
입력과 출력만 확인한다. - 오히려 이부분을 하드 코딩하자

코드 오염

테스트에만 필요한 메서드를 만들지 말자  (로그 안 찍게 만드는 스위치 메서드 등)
차라리 인터페이스를 만들어서 테스트용 구현을 새로 만든다.
인터페이스도 코드 오염의 일종이지만 구현이 없어 손상이 적다. (원래 구현도 새로 만든 인터페이스를 구현하게 됨)

구체 클래스 목으로 처리

하지 말자
구체 클래스 중 목으로 처리해야할 부분을 인터페이스로 따로 분리

---

생각

테스트 코드 개념을 처음 들었을 때, 도메인 지식 유출에 대해 생각했던 게 기억난다. 테스트 코드도 코드인데, 이 코드는 어떻게 검증하지? 였는데 정답은 로직을 짜는게 아니라 입력과 출력 케이스를 짜는 거였다.

드디어 단위테스트 책을 다 봤다. 다 봤지만 바로 적용은 아직 어려운 것 같다. 프로젝트에서 도메인 로직을 어떻게든 찾아서 작은 테스트라도 작성해봐야겠다.

책을 읽으며 얻은건 오히려 YAGNI 원칙이다. 테스트를 하고자 인터페이스를 통해 계층부터 나눌 생각을 했고, 기존의 api를 언제 다 나누지 하고 있었다. 그런데 Agile하게 하려면 오히려 해당 기능에 개선 사항이 있을 때부터 건드는 게 맞는 것 같다. 현재 repository까지 필요하지 않은 간단한 API는  service까지만 나눴다.

이 다음 책은 agile한 개발 과정이 코드와 함께 제공되는 '클린 소프트웨어' 아니면 go와 관련된 TDD 혹은 agile 책,  또는 go MSA 책이 될 것 같다.

참고

단위테스트, 블라디미르 코리코프