http://liebmona.net/mblog

JUnit에 대한 것.

– serene, 아마도 테스팅 프레임워크에 대한 접근이 상당히 피상적으로 이루어지고 있다는 이야기.

http://kr.blog.yahoo.com/kwon37xi/1236356.html

JUnit은 어렵다!!
내가 가진 JUnit을 설명한 두 권의 책(이클립스 기반 프로젝트 필수 유틸리티 CVS, Ant, JUnit, 자바 세상을 덮치는 Eclipse)은 JUnit 의 사용방법을 매우 간단하게 설명한다.

그리고 사용법은 30분이면 배울 정도로 간단하다.

헌데 이게 자바를 벗어나 DB와 연동, 혹은 파일 생성, 삭제 등과 같은 프로그램 외부에서의 변화를 끌어내는 메소드 등에 대한 테스트로 가면 아주 골치가 아픈거 같다. 실질적으로 프로그램의 확실한 실행을 보장해야 하는 부분인데 테스트는 제일 안된다.

그래서 현재는 프로그램 외부에 영향을 미치는 메소드에 대한 테스트는 안하고 있다.
그리고 메소드를 만들 때 한 메소드에 모든 기능을 뭉뚱그리지 않고 기능별로 나눠서 설계하고, 최종 DB접속 부분에 통합한다. 실질적으로 다른 모든 메소드는 다 테스트하면서 DB를 호출하는 메소드만 테스트에서 제외하게 된다. – 여기서 소스코드 복잡도가 줄어들고, 재사용성도 높아 졌다.(적어도 아직까지는)

이런 부분에 대해서는 노하우가 담긴 좀 자세한 책을 좀더 살펴봐야 할 것 같다.

어쨌든 JUnit 멋지다~!

반드시 JUnit 뿐만 아니라, ‘테스트’를 먼저 만들어 개발하자는 식의 아이디어는 널리 퍼져있지만 과연 어떻게 테스트할 것인가에 대한 공감대는 형성되지 않은 것 같아요.

사실 테스트라는건 정량적이기보다는 정성적이어서 여러가지 사안에 대한 합의는 science라기보다는 art가 아닐까요.

(1) 무엇을 테스트할 것인가 – 모두 다? 일부만?
(2) 어떤 테스트 데이터를 사용할 것인가. ‘일반적인 사용/정상적인 입력’ 이라고 말할 때 우리는 무엇을 지칭하는지
(3) 전체 데이터셋이 fix 되어있지만 무척 클 때, 어느 데이터를 테스트 샘플로 쓸 것인지. 첫번째? 끝? 중간? 만약 첫번째와 중간과 끝을 쓴다면 이 세가지 지점은 1/4, 1/8, 1/16 지점의 데이터보다 대표성이 있을런지
(4) 만약 whitebox testing을 사용한다고 가정하고, 우리가 모든 조건의 분기 상황을 꼼곰히 점검하여 테스트 한다고 할때,과연 ‘모든 조건의 분기’를 다 확인했다고 무엇으로 확인할 수 있을런지. 멀티 쓰레드라면? 사용자가 기상천외한 방법으로 메소드를 호출한다면(예를들면 specially crafted message를 보내서 Buffer overflow로 공격하는 해킹 등과 같이) 이를 어떻게 사전에 예상할 수 있을런지.

어쩌면 이런측면에서 TDD라던가, automated verfication/validation은 일종의 허상에 불과할 수 있다고 생각해요. 아니면 nonfunctional과는 다소 무관한 functional specification에 대한 automation 도구이던가.