Test 를 대하는 자세

저는

• 2014.01 ~ SI
• 2016.03 ~ NHN ticketlink
• 2017.12 ~ Naver Labs/Naver
• 2019.09 ~ Kakaopay
• 백엔드 개발자
• java/kotlin/spring framework

테스트

• 내가 작성한 코드의 동작을 확인하는 행위
• 로컬 서버 구동에서 API 호출
• 개발서버에 배포하여 애플리케이션 화면을 통해 확인
• 외부 API 를 사용하기전에 결과값을 표준출력으로 확인

코드로 하는 테스트

• 내가 작성한 코드를 또 다른 코드를 이용하여 테스트
• 특정 메서드를 실행하여 그 결과값을 출력하는것도 코드를 이용한 테스트
• 테스트하고자하는 메서드의 사전정보(파라미터 등)들을 설정해놓고 해당 메서드를 직접 호출하여 결과값을 확인
• 세상은 이미 코드로 하는 테스트를 받아들이고 있으며, 프로젝트 생성시 test 디렉토리가 기본적으로 만들어짐
• 더 쉽고 편하게 테스트 코드를 작성하는 것에 대해서도 많은 고민이 이루어지고 있으며 테스트 프레임워크인 junit, mockito 등이 존재
• spring 에서는 spring-test 라는 모듈로 테스트 프레임워크 통합

왜 코드로 테스트하는가

• 실제 QA 조직을 보유하고있는 회사는 많지 않음
• 내부 코드 변경 하나하나에 대해 QA 가 가능하지 않음
• 내가 작성한 코드의 기본적인 동작까지 QA 한테 위임하는건 이기적인 행동임

왜 코드로 테스트하는가

• 사람이 화면을 보고 진행하는 테스트는 그 행위가 축적되지 않음
• 10번째 기능을 추가했을때 앞선 9개 기능을 회귀테스트하지 않음
• 코드는 지속적으로 변경되며 10번째 기능을 개발할때 앞선 기능들에 대한 코드 변경은 의도적/비의도적으로 이루어짐
• 10번째 기능에 대해서만 테스트하고 배포 후 앞선 기능에서 문제가 생기는 경험은 서비스 개발자라면 누구나 한번 이상 경험

왜 코드로 테스트하는가

• 코드는 의도적으로 지우지 않는 이상 지속적으로 축적됨
• 10번째 기능을 개발할때도 1~9 번째 기능에 대한 테스트는 그대로 남아있음
• 테스트 코드를 실행하면 기존 기능에 대한 테스트도 함께 실행되며, 추가 기능 개발로 인해 기존 기능에 영향이 갔을 경우 기존 기능 테스트가 실패함으로써 개발자에게 피드백을 줌
• 항상 모든 기능에 대한 테스트가 있다는 안도감 내에서 개발자는 편안하게 리팩토링/프레임워크 버전업 등의 작업이 가능
• 테스트 코드를 작성하지만 전체 테스트를 실행하지 않는다거나 @Disabled 같은 기능을 사용한다면 효과는 반감

테스트코드를 작성하지 않는 이유

• 테스트 코드를 작성하면 개발 일정이 늘어난다
• 일정이 촉박해서 테스트는 일단 미룬다

테스트코드를 작성하지 않는 이유

• 테스트가 되지 않았는데 개발이 완료됐다고 할 수 있는가
• 개발완료됐다는 소식을 듣고 호출해봤는데 시작부터 문제가 있는 경우를 만난 경험이 있을 것
• A 기능을 개발해놓고 B 기능 개발에 들어갔는데 지속적으로  A 기능에 대한 버그리포트가 올라오는 경험도 있을 것
• 테스트 코드 작성은 코드 작성 그 자체로도 의미가 있지만 개발자로서 마음가짐의 문제라고 생각

테스트코드를 작성할때 고민거리

• private method 는 어떻게 테스트하는가
• service 에 비즈니스로직을 작성한 후, 테스트를 작성하려니 mocking 해야하는 필드가 너무 많다
• mock library 를 이용한 편리한 테스트 작성
• 단위 테스트와 통합 테스트

TDD

• 테스트를 작성하는 것과 TDD 는 완전히 다른 얘기
• TDD 는 테스트를 작성하는 것에서 한 발자국 더 나아가 테스트를 먼저 작성하고, 실제 로직을 작성하는 것