Junit In Action - TDD를 위한 테스트 원칙, 도구 및 활용 Review - 소프트웨어 테스트 원칙과 테스트 품질 ( 1/2 )
단위테스트를 하는 이유
단위 테스트의 핵심 목표는 애플리케이션이 예상대로 작동하는지 확인하고 사전에 버그를 찾아내는 것이다.
단위 테스트가 가지는 장점은 다음과 같다.
- 장점
- 기능 테스트만 수행했을 때보다 테스트 커버리지를 높일 수 있다 → 기능 테스트로는 수행하기 어렵거나 불가능한 오류 조건에 대해서도 쉽게 테스트할 수 있다.
- 팀 생산성이 향상된다 → 다른 컴포넌트가 준비될 때까지 기다리지 않고도 질적으로 우수한 코드를 전달할 수 있다. 기능 테스트는 어느 정도 준비가 되어야 실행 가능한 것과 대비된다
- 소스를 리팩터링 하거나 변경할 때 개발자에게 확신을 준다 → 어디에 문제가 생기는지 쉽게 알 수 있고 애플리케이션을 일일이 디버깅하지 않아도 된다
- 애플리케이션 기능 구현에 도움을 준다 → 단위 테스트가 너무 길고 다루기 힘들다면 일반적으로는 테스트 대상 코드에 설계문제가 있는 것이며 리팩터링이 필요하다. 테스트 메서드 하나가 너무 많은 기능을 테스트하고 있을 수도 있다. 격리된 상태에서 테스트가 가능을 검증하지 못한다는 건 테스트 대상 코드가 충분히 유연하지 못하며 리팩터링이 필요하다는 의미이다
- 코드의 예상 동작을 문서화 할 수 있다 → 단위 테스트는 그 자체로도 API사용 예제가 된다. 따라서 단위 테스트는 그 자체로 개발자들에게 훌륭한 설계문서 역할을 할 수 있다. 또한 현재 운영 중인 코드와 함께 업데이트되므로 일반적인 설계 문서와 달리 최신 상태를 상시 유지 한다
- 코드 커버리지를 비롯해 다양한 지표를 측정하게 해 준다 → 도구를 사용하여 진행한 빌드에서 다음 빌드까지 테스트 통과/실패의 진행 상황도 추적할 수 있다
* 애자일 개발 방법론과 단위테스트
애자일은 프로젝트 위험을 낮춰 개발자가 변화에 빠르게 대처할 수 있게 한다. 애자일은 빠른 반복을 표준화함으로써 '필요한 일만 하라'는 YAGNI(You ain't gonna need it) 원착이나 '가능한 한 가장 간단한 방법을 써라(The simplest thing that could possibly work)'와 같은 원칙을 적용하여 변화를 수용한다. 그러나 이 모든 원칙은 견고한 단위 테스트를 기반으로 한다.
테스트 유형
소프트웨어 테스트를 분류하는 방법은 다양하지만 이 글에서는 총 네 가지로 분류한다.
안쪽 상자에서 바깥쪽 상자로 갈수록 소프트웨어 테스트는 조금 더 기능적이 되며, 테스트를 실행할 때 더 많은 제반 사항을 필요로 한다.
- 단위 테스트
단위 테스트는 소스 코드의 개별 단위(메서드나 클래스)를 테스트하여 해당 코드를 사용할 수 있는지를 결정하는 소프트웨어 테스트 기법이다. 단위 테스트는 개발 과정에서 발생할 수 있는 잠재적 오류로부터 개발자를 보호하는 안전망 역할을 하므로 코드 변경을 하고자 하는 개발자에게 확신을 줄 수 있다. 좋은 단위테스트가 있다면, 변경점이 기존 기능에 영향을 미치지 않는다 확실할 수 있다.
단위 테스트에서는 개별 단위를 격리하여 테스트하는 것이 중요하다.
- 통합 테스트
단위 테스트로 개별 클래스나 메서드 테스트가 잘되었다면, 다음은 클래스나 메서드를 다른 서비스와 연결하는 과정이 필요하다. 통합 테스트는 대상 환경에서 실행 가능한 컴포넌트 간의 상호작용을 테스트하는 것이다.
통합 테스트 코드 작성은 개발자가 올바르게 동작하는 객체를 만드는 능력을 향상하는 데에 큰 도움을 준다.
아래 표는 컴포넌트 간에 상호작용하는 경우를 구분한 내용이다.
| 상호 작용 | 테스트 설명 |
| 객체 | 테스트는 객체를 인스턴스화하고 다른 객체의 메서드를 호출한다. 통합 테스트를 통해 다른 클래스에 속한 객체 간에 어떻게 협력해서 문제를 해결할 수 있는지 확인할 수 있다. |
| 서비스 | 통합 테스트는 컨테이너가 애플리케이션을 관리하는 동안 실행된다. 그동안 애플리케이션은 데이터베이스와 연동되어 있거나 다른 외부 리소스, 장치와 통신할 수 있다. 컨테이너에 배포되는 애플리케이션을 개발할 때 통합 테스트를 활용할 수 있다. |
| 서브 시스템 | 계층적 애플리케이션에서는 화면을 관리하는 프런트엔드와 비즈니스 로직을 수행하는 백엔드로 구분된다. 통합 테스트를 가지고 프런트 엔드를 통과한 요청이 백엔드에서 적절한 응답을 반환하는지 확인할 수 있다. 웹 인터페이스와 같은 프런트엔드와 비즈니스 로직을 수행하는 백엔드가 구분된 아키텍처를 가진 애플리케이션은 통합 테스트를 활용할 수 있다. |
- 시스템 테스트
시스템 테스트는 시스템이 구체화된 요구 사항을 만족하는지 평가하기 위해 완전한 통합 환경에서 수행하는 테스트를 말한다. 시스템 테스트의 목표는 통합되어 있는 단위 간의 불일치를 찾아내는 것이다. 테스트 더블이나 모의 객체를 사용하여 의존하는 컴포넌트를 테스트에 통합하는 것이 불가능하거나 지금 당장은 사용할 수 없을 때 유용하게 사용할 수 있다.
* 모의 객체 ( mock object )
일부 객체를 테스트에 통합할 수 없거나 통합할 필요가 없을 때 그 객체를 대체하는 역할
* 테스트 더블(test double)
실제 객체를 대체하기 위해 만든 것으로 실제 객체의 동작을 비슷하게 흉내 내는 데 사용함
예를 들어 테스트 시 데이터베이스가 필요할 수 있다. 데이터베이스는 설치나 구성이 금방 이루어지지 않는 대표적인 외부 서비스이다. 그럼에도 개발자들은 소프트웨어를 설치하고 테이블을 만들고 값을 채워 넣어야 한다. 이럴 경우 개발팀은 프로그램에 모의 데이터베이스를 생성하여 테스트를 진행할 수 있다.
- 인수 테스트
애플리케이션이 오류 없이 실행되는 것도 중요하지만, 애플리케이션은 반드시 고객의 필요를 만족시켜야 한다. 인수 테스트는 최종 수준의 테스트 단계라고 할 수 있다. 따라서 애플리케이션이 고객이나 이해관계자가 정의한 목표를 달성하는지 확인하기 위해 사용한다.
일반적으로 인수 테스트는 Given, When, Then 같은 키워드를 사용하여 표현할 수 있다. 해당 키워드들을 사용하여 실제 사용자가 시스템과 상호작용한다는 시나리오를 따르게 되는 것이다.
블랙박스 테스트
블랙박스 테스트(black-box test)는 시스템의 내부 상태나 동작에 대한 지식이 없을 때 수행하는 테스트다. 테스트의 정확성을 검증하기 위해 외부적인 시스템 인터페이스를 사용한다.
시스템을 테스트하기 위해서는 시스템의 기능적 명세만 알면 된다. 일반적으로 프로젝트 초기에 명세를 작성하므로 블랙박스 테스트는 비교적 일찍 시작할 수 있다. 또한 개발자가아니더라도 QA, 고객 등 누구나 시스템을 테스트할 수 있다는 것도 블랙박스 테스트의 특징이다.
간단한 예제로 인터페이스에서 수동으로 직접 해보는 것을 들 수 있다. 보다 정교한 방법을 원한다면 HttpUnit, HtmlUnit, 셀레늄과 같은 도구를 사용할 수 있다.
화이트박스 테스트
화이트박스 테스트는 다른 말로 유리 상자 테스트(glass-box testing)라고도 한다. 화이트박스 테스트는 구현에 관한 해박한 지식을 바탕으로 테스트를 만들고 테스트 프로세스를 진행한다. 테스트를 만들기 위해서는 컴포넌트 구현을 이해하는 것 외에도 테스트 프로세스가 다른 구성 요소와 상호작용하는 방식을 알아야 한다. 그러므로 일반적으로 개발자가 진행한다.
GUI를 사용하지 않더라도, 화이트박스 테스트는 프로젝트 초기 단계에서부터 구현할 수 있다. 작성되는 테스트 시나리오의 각 스텝들이 기존 API를 사용해서 만든 소스코드에 대응되기 때문이다.
블랙박스 테스트 vs 화이트박스 테스트
둘 중 절대적인 답은 없다. 테스트 시 두 가지 방식을 함께 고려하는 것이 합리적이다.
아래 표는 블랙박스테스트와 화이트박스테스트를 간단하게 비교한 내용이다.
- 각 테스트의 장점
| 블랙박스 테스트 | 화이트박스 테스트 |
| 사용자 중심적이며 설계 명세와 다른 부분이 무엇인지 바로 알 수 있다 | 프로젝트 초기부터 테스트를 구현할 수 있다 |
| 테스터가 비개발자여도 상관 없다 | GUI가 필요하지 않다 |
| 개발자와 독립적으로 수행할 수 있다 | 개발자가 제어하므로 다양한 실행 경로를 커버할 수 있다 |
- 각 테스트의 단점
| 블랙박스 테스트 | 화이트박스 테스트 |
| 입력할 수 있는 경우의 수가 제한적이다 | 프로그래밍 지식이 있는 사람만 테스트를 구현할 수 있다 |
| 커버되지 않은 실행 경로가 많을 수 있다 | 구현을 변경하려면 테스트를 다시 작성해야 한다 |
| 테스트가 중복될 수 있다. 세부 정보가 없다는 것은 동일한 실행 경로를 여러번 커버할 수 있다는 것을 의미한다 | 테스트와 구현이 밀접하게 결합되어 있다 |
간단하게 요약하면, 블랙박스 테스트는 시스템의 내부 상태나 행동에 대한 지식이 전혀 없는 상태에서 시스템 외부 인터페이스만을 가지고 시스템의 정확성을 검증한다. 반면 화이트박스 테스트는 개발자가 주로 제어하며 블랙박스 테스트보다 더 많은 실행 경로를 포함할 수 있으며 더 나은 테스트 커버리지를 얻을 수 있다.