유닛테스트의 효용성은?

아래 쓰레드에서 분기(?) 했습니다 :
http://bbs.kldp.org/viewtopic.php?p=141188#141188

단위테스트도 계속 변동하는 개념이 아닐까 합니다. 예를들어 Mock-Object 테스팅을 말씀하셨지만 In-Container테스팅이나 Mock-Object 방식의 테스팅이 널리 쓰이기 전에는 컨테이너 위에서 돌아가는 컴포넌트들에 대한 단위테스팅 자체가 그다지 실용적으로 생각되지 않았습니다. 물론 백단에서도 에러가 나지만 실제 어플리케이션에서는 자잘한 GUI의 문제점들이 사용성을 해치는 가장 큰 원인이 아닐까 생각해 봅니다.

실제 이런 문제를 개려하기 위해 GUI나 웹을 대상으로 하는 단위테스팅 프레임워크들이 등장했지만 솔직히 효용성에 대해선 의문입니다.

음... 문제는 단위테스팅을 위해서는 해당 클래스가 어떤 상태에 있어야 할 경우가 많습니다. 이런 경우 대부분 public API로 나타나진 않지만 내부에 어떤 플래그가 설정이 되어야 한다던지 하는 제약이 있을 수 있습니다. 단위 테스트는 유틸클래스의 static 메소드를 테스팅하는데 이상적이지만 특히 네트워크나 컨테이너를 포함하는 프로그램들에는 그렇지 않다고 생각합니다.

물론 Mock을 써서 해결이 되는 경우도 있지만 오히려 많은 경우 제대로된 Mock Object를 만드는게 불가능하거나 엄청난 오버헤드를 유발하는 경우가 있습니다.

예를들어 FTP 클라이언트를 만든다면 하다못해 업로드, 다운로드, 로그인 등 기본적인 기능들에 대한 단위테스트만 한다고 해도 거의 서버를 하나 만들어야 될 수준이 아닌가요? 예를들어 FTP 클라이언트 API가 접속할 URL과 계정정보를 받아서 다른 쓰레드에서 로그인 처리를 한다고 할 때, 또 만약에 이런 상황에서 다운로드 기능에 대한 단위테스트를 만들려면 어떻게 해야 할까요?

분명 public API에는 드러나지 않지만 FTP 커넥션이 있고 로그인이 된 상황에서만 다운로드가 동작하는 건 자명합니다. 그렇다면 선택의 여지는 테스트 하려는 FTP 클라이언트 모듈에 실제 로그인 정보를 주거나 아니면 스스로 접속이 되어 있다고 '믿게' 만들어야 합니다. 전자의 경우 FTP 서버 역할을 하는 Mock 프레임워크가 필요하고 후자는 단위테스팅이 아니면 불필요한 API를 추가해야 합니다.

전자의 경우 Mock 프레임워크를 만든다면 다운로드라는 단순 기능을 테스트하기 위해 일단 21번 포트를 통해 FTP와 동일한 방식으로 로그인 및 업/다운로드를 할 수 있는 가상의 FTP 서버를 만들어야 합니다. 또한 극단적인 가정이지만 만일 "1기가가 넘는 파일을 업로드할 때 문제가 없는가?"와 같은 기능을 테스트 한다면 테스트 케이스에서 로컬에 1기가 파일을 만들어서 업로드하는 기능도 필요할 것입니다.

이 정도 복잡한 Mock 프레임워크를 만드는 것은 사실상 테스트 대상인 FTP 클라이언트 만큼이나 어렵습니다. 또한 그만큼 복잡성이 증가한다는 건 단위테스트 코드 자체가 다시 단위 테스트를 요구할 정도로 버그 발생으로 인해 결함있는 테스트가 될 확률도 있다는 뜻입니다.

극단적인 예를 들었지만 주목할 점은 과연 이런 삽질을 하는 목적이 무엇인가에 대한 의문을 가져야 한다는 점입니다. 단지 'XP를 따르기 위해' 테스팅을 하는게 아니라면 위와 같은 경우는 단위테스팅이 무의미하지 않을까 싶습니다.

개발한 FTP 클라이언트가 제대로 로그인/다운로드 기능을 처리하는 지 보려면 그냥 한 번 해보는게 빠르니까요 :)