내가 작성한 코드, 팀원이 작성한 코드 등을 신뢰할 수 있도록 보조해주는 장치가 무엇일까?
대표적으로 테스트
가 존재합니다. 졸업 프로젝트, 사이드 프로젝트 등을 수행하면서 테스트 코드를 많이 작성하는가? 에 대해 네
라고 대답하기에는 어렵습니다. 빠듯한 일정, 경험 부족, 테스트를 잘 수행하고 있는지...
그럼에도 최근에 들어 사이드 프로젝트에서는 의식적인 테스트 작성을 하면서 느낀 명확한 장점들이 있습니다.
1. 내가 생각한 논리를 명확하게 검증할 수 있다
2. 예외 케이스 테스트를 생각하고 작성하면서 기존 코드 개선을 시도하게 된다
3. 프론트엔드 개발자들과 협업하며 불안 요소를 줄였고, 반복하는 작업이 줄었다
테스트에 대해 소홀하게 할수록 반복적인 작업이 늘어나고 시간을 낭비하게 되는데 이에 대해 많이 개선해보았던, 그리고 도움을 받았던 스토리를 소개합니다.
내가 정의한 데이터 형태를 기반으로 의존 관계는 걷어내고 테스트 하고자 하는 하나의 기능, 메서드의 로직을 빠르게 검증할 수 있다. 순서와 논리를 통해 호출 여부를 검증할 수도, 데이터의 상태 값을 통해 명확한 비교도 가능하기에 작은 단위에서부터의 시작은 쌓여가는 테스트 코드들의 신뢰성을 더 높일 수 있다고 생각합니다.
서적을 읽다보면, 테스트에 대한 런던파 스타일과 고전파 스타일이 존재하는데, 제가 수행한 방법은 Mockito를 통해 의존성을 테스트 대역으로 대체하고 고립시켜서 수행했습니다.
Database를 액세스하는 쿼리에 대한 테스트도 검증할 수 있는데, 이는 실제 데이터베이스에 잘 저장됐는지, 원하는 데이터들이 조회되는지, 수정됐는지 등등 기본적인 CRUD를 확인할 수 있을 뿐만 아니라 쿼리가 복잡해질수록 신뢰를 보장해줄 수 있다.
시스템에 넘어오는 데이터의 형태는 항상 똑같거나, 개발자가 생각한 형태만 존재할까?
모르는 일이라고 생각합니다. 따라서, 변수를 항상 염두해두고 안전하게 코드를 작성하는 것도 개발자의 책임이라고 생각됩니다. 테스트 코드만 작성했다고 코드의 급격하게 신뢰성이 올라가지는 않기에, Input으로 들어오는 데이터를 Random하게 생성해주고 검증 장치가 정확하게 동작하는지 여부를 확인할 수 있습니다.
이를 도와주는 도구가 있습니다. 저희 프로젝트 팀은 이 도구를 도입하여 실제 큰 효과를 보고 있습니다.
해당 도구: Naver Fixture Monkey
내가 수행했던 테스트는 통과하더라도, 갑작스럽게 CI과정에서 테스트가 실패했던 경험이 있습니다. 검증 장치를 통해 데이터가 필터링 되어 개발자가 정의한 데이터의 형태 또는 값의 범위 등을 벗어나 테스트 코드를 개선해 나아간 사례가 있습니다.
기존에는 Fixture를 만드는 코드가 중복이 발생하기도 하고, 다양한 예외 검증을 하지 못했습니다. 기술의 도움을 받아서 Fixture를 간단하게 생성할 수 있었고 생산성을 높일 수 있었습니다.
프로젝트에서 사용하는 기술들이 많이 존재하면 존재할수록 통합 테스트를 위한 환경 구축이 까다롭습니다.
매번 반복적으로 불필요한 시간 낭비를 줄이고 테스트에 집중할 수 있는 방법
이 있습니다. TestContainers를 이용하면 개인 환경에 Docker Engine만 설치되어 있다면, 통합 테스트를 쉽게 실행할 수 있습니다. Database, Cache 등 구성만 요구사항에 맞게 설정한다면 쉽게 실행됩니다. 해당 설정 방법은 TestContainers 공식 문서에서 확인할 수 있습니다.
환경 구성 설정을 작성하기
Ex) Database : MySQL, Cache: Redis
CI 과정에서 테스트 자동화 및 커버리지 측정
수행하는 프로젝트: https://github.com/CAKK-DEV/cakk-server
알아가면 좋은 내용 TestContainers 동작을 위해서는 Container Engine이 필요하다고 했다. Github Actions를 통해 CI를 구성하게 되면, Default로 Docker Environment를 제공받기 때문에 추가적으로 환경 제공을 명시할 필요가 없어서 편하다.