실용적이고 안정감있는 테스트 코드 작성하기

서론

개발을 할 때면, 좋은 테스트를 작성하기 위해 매번 많은 고민을 통해 꽤 긴 시간을 허비하게된다.

현 세계에는 E2E Test, Integration Test, Unit Test 등 많은 테스트 기법들이 있지만, 현재 속해있는 조직에선 Unit Test를 위주로 작성 하고있다. 유닛 테스트만 작성하는 이유는 몇 가지가 있겠지만, 그 중 개인적으로 가장 타당하다고 생각드는 부분은 다음과 같다.

 

우리의 시스템은 주어진 요구사항이 Domain Model Layer에 응집되도록 하고있다. 이 응집된 Domain Model이 보통 단위의 대상이 되도록 하고있다. 따라서, Domain-Model의 테스팅이 성공된다면, 우리의 복잡한 요구사항은 얼추 만족시키게 되는것이다. 이 도메인 논리에 대해 촘촘하게 작성만 된다면, 대부분 성공한다는 어떻게보면 낙관적(?)으로 생각하고 나머지 의존성들을 조립한다.

 

그러나, 이렇게 진행할 경우 도메인 모델의 외부 모듈인 Controller나 Infra Layer 등 에서 의존성들이 제대로 조립이 안되거나, Route 설정이 잘못되어있다거나 했을 때, 개발계에 배포 후 인수테스트에서 실패하는 경험을 맛볼 수 있다.

 

그런데 왜 Unit Test만 하고있나요? 라고 질문을 할 수 있다. 그에 개인적인 생각을 말해보자면, E2E Test나 Contract Test를 작성하기 위해선 많은 리소스가 추가적으로 들게된다. 현재 팀(스쿼드) 구성, 그리고 아키텍처 구성을 고려해보았을 때, 위 테스트까지 고려하여 작성한다면 더욱 더 많은 시간이 들게된다. 이를 트레이드 오프라 생각하고, 주어진 시간안에 빠르게 요구사항을 만족할 수 있는 유닛 테스트를 작성하기위해 노력하고있다.

 

위에서 언급한 아키텍처 구성이 어떻길래 그런지에 대해 간략히 말해보자면, MSA로 이루어진 분산 시스템에서 대부분의 서비스가 Event Driven Architecture로 이루어져있다. 일반적인 API를 호출하여, 응답을 뱉어주고 이런 형식이 아닌 각 도메인 서버에서 발행되는 도메인 이벤트를 발행/소비를 통해 각 서비스에서 처리하고있다.

 

이럴 경우, 통합 테스트를 작성한다고 하면, 매우 험난한 여정이 될게 불보듯 뻔하다. 현재 속해있는 팀은 아직 신사업 팀으로, 곧 런칭을 앞두고 있는 소규모 팀이다. 소규모 팀에서 위 테스트 환경을 모두 챙기기에 어려움이 있는 상황이다. (물론, 추후에는 더 많은 동료들과 함께 위 여정을 같이 만들어 가야된다고 생각한다.)

 

현재 우리는 주어진 요구사항을 최소한으로 빠르게 만족시키고, 애자일하게 런칭을 위해 빠르고 민첩하게 고객들을 만족시킬 수 있는 제품을 만들어나가야한다는 사명도 있다. 이와 같이 팀의 상황은 모두 다르기에, 적절한 테스팅이 필요하다고 생각이 든다.

 

그래서, 이번 글에서는 앞으로 더욱 더 좋은 테스트를 작성하기 위해 테스트 관련된 책을 읽으면서 도움이 되고, 내 코드에 동기화 시키는데 도움이 될만한 내용들을 스터디 하는겸 글로 작성해볼 예정이다. (즉, 이 글은 한번의 발행으로 끝이 아닌 틈틈이 보강이 될 예정이다.)

 

작성 방식은 꽤나 덩어리가 큰 테스트 기법들이 주제로 삼아 작성해보려고 한다. 그럼 시작해보자.

 

명세 기반 테스트

이 기법은 애자일의 유저 스토리나 UML의 유즈케이스 같은 프로그램 요구사항을 테스트하는 기법을 말한다.

일반적으로 테스트를 작성할 때 이번에 알았지만, 명세 기반 테스트를 위주로 작성하고 있는 것 같았다.

 

이 기법을 사용하기 위해선 우리가 먼저 알아야 할 내용은 다음과 같다.

• 요구사항은 테스트를 만드는 가장 중요한 참고 자료가 된다.

일반적으로, 개발자 입장에서 구현하려는 기능이 곧 요구사항이다. 다시 말해, 요구사항이 우리의 주요 비지니스 논리가 되는것이고, 우리는 이 요구사항을 만족시키기 위해 노력할 수 밖에 없다. 그래서 요구사항은 우리에게 가장 중요한 자료가 될 수 밖에 없는것이다.

 

이 요구사항을 이용하여 명세 기반 테스트를 접근하는 방법을 아래와 같이 소개한다.

 

* 명세 기반 테스팅 7단계 접근법

1. 주어진 요구사항 이해하기
2. 프로그램에 대한 이해도가 낮을 땐, 프로그램(시스템)을 탐색해보기
3. 입출력의 특성을 꼼꼼하게 분석하여, 구획을 식별하기
4. 테스트 경계 분석하기
5. 구체적인 테스트 케이스 고안하기
6. 구체적인 테스트 케이스들로 테스트 자동화 구현하기
7. 이 후 창의성과 경험을 통해 테스트 스위트 강화하기

버그는 경계를 좋아한다. 하지만 경계를 식별하는 일은 명세 테스트에서 가장 어려운 부분일 수 있다. 단순한 프로그램에서도 테스트 케이스의 수가 매우 늘어날 수 있다. 무엇을 테스트 해야하고, 무엇을 테스트 해서는 안되는지 결정도 필요하다.

 

최근 진행하고 있는 사이드 프로젝트에서 Tag라는 Entity를 생성하는 UseCase가 있었다. 주어진 요구 사항은 다음과 같았다.

• 요청 Command로 태그 엔터티를 만들어야한다.
• 최대 3개의 태그를 만들 수 있다.
• 태그의 글자 수는 15자로 제한한다.
• 이미 같은 이름으로 태그가 있다면, 예외를 반환하도록 한다.

위와 같은 인수 조건들이 있을 때, 위 명세 기반 테스트 기법을 기반으로 작성했던 케이스가 있다.

코드는 <링크>를 참고하면 볼 수 있다.