유닛 테스트와 화이트박스/블랙박스 테스트

leafriend의 이미지

제가 작업을 하다가 XML 파일에서 설정을 읽어오는 컴포넌트를 작성하게 됐습니다.
마침 얼마 전 켄트 벡이 쓴 테스트 주도 개발을 읽은 터라 컴포넌트 메서드 중
비즈니스 로직이 있는 녀석들의 테스트를 먼저 작성하였습니다. 그런데 XML 파일
경로가 설정된 다음 설정을 읽어오는 메서드의 테스트를 작성하다 보니 다음과 같은
생각이 들더군요.

1. 상태

제가 작성한 컴포넌트는 XML 파일 경로을 내부 필드로 가지는 상태를 가지는
객체입니다. 물론 XML 파일 경로를 입수로 변경함으로써 객체의 상태를 제거할 수는
있겠지요. 하지만 그러기 위해서는 XML 파일 경로를 호출하는 쪽에서 알고 있어야
하고, XML 파일 경로 자체도 시스템의 설정(configuration)이라 결국 상태가 작성하던
컴포넌트에서 다른 컴포넌트로 이동할 뿐 없어지지는 않더군요. 그래서 상태를 가져야
한다면 컴포넌트가 상태(XML 파일 경로)를 가지고 있는게 응집성을 높일 수 있다고
판단했습니다..

컴포넌트가 상태(XML 파일 경로)에 따라 동작(XML에서 설정 읽기)을 다르게 하기 때문에
테스트를 할 때 컴포넌트의 내부 상태를 알고 테스트를 해야 합니다. 심지어 원하는 기능을
테스트하기 위해 컴포넌트의 상태를 임의의 상태로 조작하기도 하게 됩니다.

이렇게 테스트 대상의 상태를 알고 있어야 하기 때문에 유닛 테스트를 화이트박스 테스트로
작성하게 되더군요.

2. 로직

메서드의 로직도 화이트박스 테스트를 작성하게 합니다. 주어진 XML 파일 경로에서
내용을 읽어올 때 문자열로 구성된 경로를 XML 파일에 대한 경로로 해석을 하고
스트림을 열어서 해석(parse)을 시도하는 내부 로직이 정상적으로 작동하는지
테스트하기 위해서는 필연적으로 테스트 코드가 모델(테스트 대상)의 내부 로직을
알아야겠죠.

그런데 여기서 반전이 있습니다. 이렇게 글을 작성하다 보니 화이트박스로 작성된
테스트를 블랙박스로 바꿀 실마리가 보이네요. -ㅅ-; 유닛 테스트가 반드시
블랙박스여야 한다는 법은 없겠지만 그래도 한 번 시도해봐야겠습니다.

moonend의 이미지

이런저런 설정 파일들을 읽어들이다보면 너무나도 많은 정보를 필요로 합니다.
내가 화이트박스 테스트를 하는지, 블랙박스 테스트를 하는지 구분하기가 애매해지더군요...

leafriend의 이미지

화이트박스 테스트가 블랙박스 테스트보다 못하거나 하지는 않죠.
다만 테스트를 하기 위한 준비(set up)이 너무 많다 싶으면
기능을 분리하는 것도 도움이 되더라구요.

M.W.Park의 이미지

일반적으로 말해서...
(코드가 없어서 자세한 상태는 모르겠지만)
테스트하기 힘든 모듈이나 함수는 다시 한번 점검해야합니다.
실제 그 모듈이나 함수를 사용할 때에도 비슷한 이유로 버그를 끌어들일 소지가 많습니다.

그리고 글 쓰신 분의 현재 상황에 한정해서 하나만 더 첨언하자면...
인터페이스만 가지고 테스트할 수는 없는 상황인가요? 굳이 내부 로직을 노출시켜야할 필요는 없어보이는데요.

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂