TDD 좀 더 잘하기

표지

아래 내용은 고품질 쾌속개발을 위한 TDD 3장 내용을 발췌했습니다.

TDD의 한계

이번 장에서는 TDD의 한계 라는 주제로 내용만 다룰까 합니다.

동시성 문제

동시성이 필요한 테스트케이스의 경우, 작성하는데는 문제가 어렵지 않다. 그러나, 테스트 자체를 무결하게 유지하기가 매우 어렵다. 상식적으로 파악하기 어려운 불규칙한 문제가 적지 않게 발생하기 때문이다. 현재 유일한 해결책을 제시하기는 어렵지만 다양한 방식으로 해결한다 그러나 여전히 명확하게 테스트할 수 있는 것은 없는 것 같다.

접근제어자(private/protected 메서드) 

 테스트할 항목의 접근 제한에 대한 논의. private으로 되어 있는 메소드는 일반적인 방법으로는 테스트가 불가능하다. 그러나, private으로 되어 있어서 접근이 어려운 메소드의 테스트 필요성 자체에 대한 논의가 먼저 필요하다. 현재는 "public 으로 되어 있는 메소드만 테스트해도 무방하다' 라는 경향이 대세인 것으로 보인다. 왜냐하면, private 메소드는 public에서 사용하는 함수이기 때문에 함께 테스트 된다고 말 할 수 있다. 다만, 경우에 따라 우선은 모든 메소드를 public으로 만들어서 테스트가 끝난 다음, 차후에 판단하여 public을 private으로 바꾸는 식의 범위(scope)를 줄이는 형태로 접근하는 것도 한 가지 방법. 

GUI

 GUI 애플리케이션에 대한 테스트 작성이다. 이는 심미적인 부분이 강하고, 사용자의 동작에 따라 화면이 많은 영향을 받기 때문에 단순히 '결과상태예상 > 수행 > 확인' 순으로 테스트하기가 어렵거나 복잡해진다. 웹 애플리케이션 같은 경우엔 뷰(View)에 해당하는 영역 이 TDD를 적용하기 곤란한 GUI 영역이다. HttpUnit이라든가, Selenium이라든가 하 는 식의 테스트 지원 툴도 존재하지만, 아직까지는 활발히 사용되고 있진 않다. 노력 을 들여 테스트 케이스를 작성하는 경우에도, 대부분은 자동화된 기능 테스트의 의미 가 더 강하다.

의존성 모듈 테스트(target = A but A -> B)

테스트하려는 부분에 의존성이 있는 모듈을 사용하고 있는 경우의 테스트도 종종 문제가 된다. 즉, '테스트의 대상이 되는 A가 기타 메소드나 클래스를 참조하고 있을 경우, 그리고 해당 참조 부분에 대한 접근이 쉽지 않을 경우에 B는 어떻게 할 것인가?' 라는 문제다. B가 아무런 문제 없이 확실한 모듈이라면 상관없는데, 그렇지 않다면 문제의 소지가 있는 부분이다. 이럴 떄는 B를 둘러싼 일종의 프록시 클래스를 하나 만들어서 온전히 B부터 테스트하는 방식으로 접근하는 방식을 취하든가, 아니면 B를 신뢰한다는 가정하에서 A만을 테스트한다. 보통은, Mock 객체를 많이 사용한다.