화이트박스 테스트

화이트박스 테스트는 코드를 읽고 테스트를 설계합니다. 테스터(대개는 개발자)가 분기, 조건, 반복문, 오류 처리를 살펴보고 이를 의도적으로 실행하는 테스트를 작성합니다. 글래스박스(glass-box), 클리어박스(clear-box), 구조 기반(structural) 테스트라고도 부릅니다. 가장 흔한 형태는 단위 테스트이며, 일반적인 측정 지표는 코드 커버리지입니다.

예시

String grade(int score) {
    if (score < 0 || score > 100) {
        throw new IllegalArgumentException("score out of range");
    }
    if (score >= 50) {
        return "PASS";
    }
    return "FAIL";
}

코드를 읽어 보면 결과가 세 가지(예외, PASS, FAIL)이고, 첫 번째 if에는 각각 예외를 일으킬 수 있는 두 개의 독립된 조건이 있다는 것을 알 수 있습니다. 구조를 기준으로 고른 테스트는 다음과 같습니다.

입력	실행되는 경로
-1	score < 0 참, 예외
101	score > 100 참, 예외
50	범위 내, score >= 50 참, PASS
49	범위 내, score >= 50 거짓, FAIL

이 테스트들로 분기 커버리지와 조건 커버리지를 모두 100% 달성합니다. 정확히 50과 49를 테스트하면 >=를 실수로 >로 쓴 경우도 잡아낼 수 있습니다.

화이트박스 테스트와 블랙박스 테스트의 차이

화이트박스는 “이 코드의 모든 경로가 올바르게 동작하는가?“를 묻고 소스 코드가 필요합니다. 블랙박스는 “시스템이 요구사항대로 동작하는가?“를 묻고 명세만 있으면 됩니다. 화이트박스는 테스트되지 않은 경로, 죽은 코드(dead code), 분기 안의 로직 오류를 찾아냅니다. 블랙박스는 누락된 기능과 요구사항에 어긋나는 동작을 찾아내는데, 누락된 기능에는 코드가 없으므로 화이트박스로는 볼 수 없습니다. 좋은 스위트는 두 가지를 모두 사용합니다.

한계

• 테스트가 코드의 실수를 그대로 베낄 수 있습니다. 개발자가 요구사항을 잘못 이해했다면, 코드를 보고 작성한 테스트는 잘못된 동작을 그대로 확인해 줄 뿐입니다.
• 강한 결합. private 메서드나 내부 구조에 의존하는 테스트는 동작이 바뀌지 않아도 리팩터링할 때마다 깨집니다. 가능하면 public 인터페이스를 통해 테스트하십시오.
• 커버리지는 정확성이 아닙니다. 모든 분기를 실행했다고 해서 어설션이 의미 있다는 보장은 없습니다.