단위 테스트를 작성하는 일은 검증의 의미도 있지만 설계의 문제이기도 하다. 또한 문서화의 문제이기도 하다.
테스트 주도 개발 (TDD)
테스트 주도 개발은 프로그램을 설계하기 전에 먼저 테스트를 설계하고, 어떠한 기능을 구현하기 전에 먼저 그 기능에 대한 테스트를 작성하는 말 그대로 테스트를 기반으로 개발을 진행하는 방식이다. 이러한 TDD 방식이 유행하고 뜨고 있는 이유는 무엇일까?
TDD의 장점
① 프로그램의 모든 단일 함수가 그 동작을 검증하는 테스트를 갖게 된다.
- 일차적이고 가장 명백한 효과
- 개발자가 어떠한 기능을 부주의하게 망가뜨릴 때마다 그 사실을 알려줌
- 지속적으로 위와 같은 사실을 알려주므로 자유롭게 프로그램을 수정, 개선 가능
② 다른 관점에서 문제를 해결할 수 있다.
- 매우 중요한 장점
- 작성할 프로그램을 그 프로그램의 호출자 관점에서 보게 됨.
- 그렇다보니 자연스럽게 편리하게 호출할 수 있는 소프트웨어를 설계
③ 자신이 반드시 테스트 가능한 프로그램을 설계하도록 강제할 수 있다.
- 테스트를 먼저 작성하고 그 테스트를 통과하도록 프로그램을 설계하다보니 자연스럽게 테스트 가능한 프로그램을 설계
- 호출 가능하고 테스트가 가능한 프로그램을 설계하는 것은 매우 중요
- 호출 가능하고 테스트가 가능하려면 소프트웨어가 다른 환경과 분리되어야 함 (매우 중요)
- 이러한 분리로 인해 변화를 잘 수용할 수 있는 유연한 소프트웨어 구조를 가질 수 있음
④ 테스트가 문서화의 귀중한 한 형태로 기능할 수 있다.
- 어떤 함수를 호출하거나 어떤 객체를 생성하는 방법을 알고 싶다면 그것의 테스트를 보면 됨.
- 그 코드를 사용하는 방법을 알게 도와주는 예제 집합으로서의 역할
- 컴파일 및 실행이 가능하며, 항상 최근 상태를 반영하고, 거짓을 보여줄 수 없는 문서화
인수 테스트
① 화이트박스 vs 블랙박스
단위 테스트는 필수적이고 시스템의 작은 구성 요소가 기대한 대로 동작하는지 여부를 검증할 수 있다. 하지만 시스템 전체로서 제대로 작동하는지는 검증하지 않는다. 즉 단위 테스트는 시스템의 개별적 메커니즘을 검증하는 화이트박스 테스트이다. 이와 다르게 인수 테스트는 그 모듈의 내부 구조, 메커니즘을 모르는 상태로 고객의 요구사항이 충족되고 있는지를 중심으로 검증하는 블랙박스 테스트이다.
② 시스템 내부 요소를 위한 문서 vs 기능 요소를 위한 문서
인수 테스트는 즉 시스템의 내부 메커니즘을 알지 못하는 사람이 작성한다. 그리고 이런 인수 테스트도 프로그램이기에 실행 가능해야한다. 인수 테스트는 기능 요소의 궁극적인 문서화 형태이며 프로그래머는 이 인수 테스트를 보고 정확하게 기능 요소를 이해할 수 있다. 단위 테스트가 시스템 내부 요소를 위한 컴파일 가능하고 실행 가능한 문서로서의 역할이라면 인수 테스트는 시스템의 기능 요소를 위한 컴파일 가능하고 실행 가능한 문서로서의 역할인 것이다.
③ 작은 단위 설계 vs 큰 단위 설계
단위 테스트처럼 인수 테스트도 먼저 작성할 경우 시스템의 아키텍처에 큰 영향을 줄 수 있다. 시스템을 테스트 가능하게 하려면 상위 아키텍처 수준에서 주위 환경으로부터 분리되어야하기 때문이다. 즉 단위 테스트는 프로그래머로 하여금 작은 단위에서 뛰어난 설계 의사 결정을 할 수 있게 만들고 인수 테스트는 큰 단위에서 뛰어난 아키텍처 의사결정을 할 수 있게 해준다.
결론
테스트를 실행하는 것이 간단할 수록 테스트가 좀 더 자주 실행되며, 테스트를 자주 많이 살행할수록 어긋나는 것들을 좀 더 빨리 찾게 된다. 검증은 테스트 작성이 주는 이점 중 하나일 뿐이며 단위 테스트, 인수 테스트 모두 정확하고 신뢰성이 있는 컴파일 및 실행가능한 문서의 기능도 할 수 있다.
단위 테스트는 프로그래밍 언어로 작성되기 때문에 당연히 프로그래머가 읽을 수 있고, 인수 테스트는 고객이 설계한 언어로 작성되기 때문에 고객도 읽을 수 있다. 즉 테스트는 그것을 보는 사람이 읽을 수 있도록 모호하지 않은 언어로 작성된다.
결과적으로 테스트 작업에서 얻을 수 있는 가장 중요한 장점은 아키텍처와 설계에 미치는 효과이다. 테스트 가능하게 만들기 위해서는 주위 환경으로부터 분리해야해야 한다. 이렇게 주위 환경과 분리하고 포괄적인 테스트를 고려하는 활동은 소프트웨어의 구조에 매우 좋은 영향을 미친다.
