본문에 들어가기 전
박우빈님의 강의를 “거의” 들으며 테스트에 대한 시각의 변경점이 있어 정리해보려고 합니다.
코드나 개발에는 반드시 “정답”은 없다고 생각하며 이 글 또한 테스트에 대한 새로운 관점을 받아들이며 정리한 글임을 밝힙니다.
테스트를 바라보는 방식
테스트는 문서다
박우빈 강사님은
테스트는 문서다
라고 이야기하십니다. 테스트는 단순히 현재 기능이 정상 동작하는지를 확인하는 것을 넘어 개발 동료에게 해당 메서드가 어떤 동작을 하는 것인지 알려주는 문서라고 생각한다고 합니다.
저는 위 강의를 들으며 문서로서 동작하게된 계기가 궁금해지기 시작하였습니다.
문서와 비교
기존 프로젝트를 진행하며 저는 위와 같이 명세서를 문서로 작성하였습니다.
물론 위의 과정이 중요하지만 개발자의 입장에서 Todo 수정이라는 흐름을 알아보려면 저 API로 넘어가는 컨트롤러를 찾은 후 내부 동작을 확인하여야 합니다.
특히 코드의 컨트롤러를 본 후 API 명세서를 확인하고 다시 코드를 확인한다면 코드 → 문서 → 코드라는 번거로운 과정이 존재합니다.
하지만 테스트를 작성해둔다면 테스트 명에서 Todo 제목, 내용 수정 성공이라는 테스트를 보고 바로 해당 API가 어떤 동작을 진행하는지 개발자는 더 빠르게 확인할 수 있습니다.
DisplayName 어노테이션
개발자라면 변수 명과 같은 이름들을 짓는 것이 가독성에 얼마나 도움이 되는지 이해하고 있을 것입니다. 이때 DisplayName은 기존 변수명과 다르게 테스트 설명을 길게 적을 수 있는 아주 유용한 어노테이션임을 알 수 있습니다.
제가 기존에 작성했던 테스트의 이름입니다. PUT 요청이 제대로 변환되는지 확인이라는 테스트 명이 존재합니다. 만약 이 코드를 처음보는 개발자라면 어떤 생각이 들까요?
아마 다음과 같은 질문들이 떠오를 것입니다.
- 어떤 것을 바꾸는 PUT 요청이지?
- PUT 요청을 변환한다는게 무슨 소리지?
- 우리가 검증했던 저 메서드는 어디에 사용하는 것이지?
위 질문을 포함하여 다양한 질문이 떠오를 것입니다. 사실 저 테스트는 문서로서 전혀 기능을 하고있지 못합니다.
가장 좋은 해결법은 테스트의 이름을 실제 도메인 명을 사용하여 작성하는 것입니다.
만약 위 테스트를 지금 다시 작성한다면 다음과 같이 테스트 명을 작성할 것입니다.
Daily의 제목, 내용, 마감일 수정 API의 Request body를 dto로 변환한다.
도메인을 사용하여 누구나 쉽게 알아볼 수 있고 명확한 테스트 주제를 알려줄 수 있도록 테스트 명을 제작하여야 합니다.
테스트는 어떻게 제작되어야 하는가
테스트의 복잡성의 최소화
테스트의 복잡함을 최소화하여야 합니다.
for, if와 같은 반복문, 조건절이 부여된다면 코드를 읽는 것에 상당한 부담감을 느끼게 될 것입니다.
또한 0 ~ 100의 숫자는 성공, 그 외의 숫자가 실패된다면 모든 숫자를 넣어보는 방법이 옳을까요?
물론 테스트의 견고함은 좋아지겠지만 테스트를 실행하는 비용과 시간이 커지게되며 전체를 테스트하는 것은 비효율적인 테스트를 한다고 생각할 수 있습니다.
따라서 엣지 케이스인 -1, 0, 100, 101을 테스트하는 것으로 해당 메서드의 테스트를 간단하게 테스트할 수 있을 것입니다.
테스트 로직의 반복 최소화
그렇다면 -1, 101의 경우 같은 테스트 환경을 구축하고 같은 코드를 사용하여 비효율적이라고 생각할 수 있습니다. 이 부분에서는 다음과 같은 ParameterizedTest 어노테이션을 통해 간단하게 해결할 수 있습니다.
테스트 코드 메서드만 보고 이해할 수 있도록
테스트 코드는 간단해야한다는 것을 강조하고 있습니다.
따라서 모든 테스트가 실행되기 전 데이터를 추가시키는 과정을 없애기 위해 BeforeEach 혹은 BeforeAll과 같은 어노테이션을 사용하여 작성된 것은 옳은 방식일까요?
이 코드를 보고 어떤 생각이 드시나요?
기간을 정했는데 현재 데이터에 어떤 기간이 존재하고 따라서 왜 조회가 되지 않았는지 보고싶다는 생각을 하고 싶지 않나요?
그렇다면 제일 위의 데이터를 추가하는 부분을 찾아가기 위해 스크롤을 올려 확인합니다.
놀랍게도 여기서 모든 데이터는 추가되고 있었고
필드에서 다음과 같이 데이터가 추가적으로 만들어지고 있음을 확인할 수 있습니다.
1개의 테스트를 보기 위해 하나의 자바 파일에서 3개의 구간을 확인하고 읽어야하는 어려움이 존재하게 됩니다.
이런 것들을 최대한 지양하여 코드를 작성하는 것이 중요합니다.
정리
코드는 문서다라는 간단한 말로 시작하여 테스트 코드는 쉽게 읽히고 테스트 명은 도메인 용어를 활용하여 어떤 사람이 읽어도 쉽게 내용을 이해할 수 있도록 작성되야함을 강조하고 있습니다.
만약 테스트 코드를 작성함에 있어서 복잡성이 증가하거나 BeforeAll, BeforeEach와 같이 분리를 해야한다면 “테스트는 문서다”라는 것을 기억하고 해결책을 모색하는 것이 더 좋은 테스트를 만들 수 있는 방향이라고 생각합니다.
