먼저 TDD에서 도입하는 유닛 테스트를 이해하기 위해서 기존의 테스트 프로세스를 먼저 살펴볼 필요가 있다. 대부분의 프로젝트에서는 통합 테스트(Integration Test)를 통하여 소프트웨어를 테스트하고 진단하게 된다. 먼저, 우리가 운전하고 있는 자동차가 어떤 문제가 생기면 어떻게 될까? 혼자서 문제를 진단하고 알아 내는 것이 과연 가능할까? 자동차의 엔진들은 보통 많은 부품들과 함께 작동되기 때문에 어떤 것들이 어떻게 연결되어 있는지 알아야만 진단이 가능하다.
아쉽게도 소프트웨어도 자동차의 엔진과 굉장히 비슷하다. 많은 엔진들과 기능들이 서로 모듈 별로 연결되어 있기 때문에 어떤 한 모듈이라도 제대로 동작되지 않으면 전체 기능이 동작되지 않게 되는 경우가 많다. 아래 [그림3]의 여러 층으로 설계 된 웹 애플리케이션의 경우를 살펴보자.
[그림3] N-레이어 기반 애플리케이션
[그림3]에서와 같이 여러 개의 버그 포인트를 가지고 있고 여러 개의 의존성을 가지고 있는 환경의 테스트를 통합 테스트(Integration Test)로 불리고 있는데 빌 해트젤(Bill Hetzel)에 의해서 이 용어가 처음 정의 되었다.
댓글을 버튼을 눌렀을 때 데이터 베이스까지의 작업을 하나로 묶어서 통합 테스팅을 진행할 경우에 문제는 무엇일까? 먼저 가장 큰 문제는 우리가 테스트를 자동화 시킨다 한들 실제 버그가 일어날 경우에 어떤 모듈에서 진행되는지 알 수 없다는 것이다. 문제를 조금 더 심화시켜 보자면 여러 모듈을 사용하고 있는데 이 모듈들은 다른 팀들에서 각자 개발되었다고 가정해보자. 이런 환경에서 소프트웨어에 문제가 생길 경우 과연 어떤 팀의 문제인지 쉽게 진단해 낼 수 있을까? 그럼 어느 팀에서 이 문제를 분석해서 알려주어야 할 것인가? 프레젠테이션 팀에서 무조건 이 책임을 짊어져야 하는 것인가?
두 번째는 특정 모듈이 변경되었다면 어떨까? 연관성이 있는 모든 코드들을 다시 테스팅 해야 한다는 것이다. 그런데 더 큰 문제는 테스트를 바로 바로 진행하지 않았기 때문에 지금 변경한 모듈 때문에 실패한 것인지 아니면 이전에 변경한 코드 때문에 실패한 것인지 알 수 없다면 어떨까? 이때 우리는 심증으로 이야기 할 수 밖에 없다. “이 모듈이 동작이 안 되는 것 같은데 한번 봐주실 수 있으신가요?” 라고 물어 볼 수도 있고 “확인해 봤는데요 제 모듈 쪽에서는 문제가 없는 것 가은데요” 라며 대답할 수도 있을 것이다.
이러한 통합 테스트의 문제를 우리는 유닛 테스트와 NUnit, MSTest 과 같은 유닛 테스트 프레임워크를 도입함으로 해결 할 수 있다. 유닛 테스트은 말 그대로 하나의 작은 유닛 단위로 테스트 코드를 작성하여 테스트를 자동화 시키는 것을 말한다. 즉, 유닛 테스트는 각 코드 단위 별로 어떤 변경과 문제가 있을 때마다 자동으로 알려주는 것이 가능하기 때문에 더 이상 문제를 찾기 위해서 그렇게 곤욕을 치루지 않아도 된다.
한가지 오해하면 안되는 것이 있다면 TDD를 한다고 해서 통합 테스트가 필요 없다는 것이 아니다. 뒷부분에서 다룰 내용이지만 유닛테스트 원칙을 유지하는 부분 때문에 실제 DB나 외부 리소스와 연동한 테스트를 진행하는 부분에서 유닛 테스트를 진행하기 힘든 부분이 있다. 때문에 이런 부분은 반드시 통합 테스트 코드를 작성해야 한다.
댓글을 달아 주세요