TDD를 교육받고 아주 좋은 것이구나!라고 공감을 해도 쉽사리 프로그래밍에 적용하기 쉽지 않다. 특히 복잡한 환경일수록 여러 애플리케이션간의 종속관계에 Mock객체의 필요성을 느낌과 동시에 귀차니즘이 발동하게 되어 그냥 하던데로 하는 경우도 많았다. 

현재 진행중인 프로젝트 같이 PMD rule check 및 Test Code의 coverage를 일정수준 까지 맞춰야하는 환경이 있었다. 하지만 REST, Hadoop Infra 등등 외부종속적인 코드를 테스트하기는 쉽지 않았다. 그러면서 사용했던 것이 Mock. 그러면서 자연스레 Stub까지 공부하게 되었다.


 Stub Mock 
-Database, file system, web server 등 과의 의존성을 분리하기 위해 주로 쓰임
-Stub객체는 모든 로직을 구현
-Test를 위해 Test대상의 class를 수정해서는 안됨
-Stub은 단순해야하고 또다른 application이 되어서는 안됨 
-단위 단위 Test의 용이(하나의 Method에 집중)
-비지니스 로직이 없다
-test대상 class의 어느정도의 코드 수정은 용인
-오픈소스 프레임웍 (EasyMock, Mockito)활용 가능

즉 test 대상이되는 class가 호출하는 클래스의 메서드를 stub으로 구현해야 하기 때문에 또 그 클래스의 메서드가 또다른 stub을 호출하게 되는 상황이 발생할 수 도 있기때문에 일단 생산성이 떨어진다고 본다. 하지만 Mock객체는 소스를 수정해야(아주 약간?)하는 귀차니즘과 위험부담을 감수한다면 유저가 정의 한 Mock객체를 활용하여 아주 간단히 단위 테스트를 마칠 수 있다.

TO SUM UP......
내가 잘못 이해한 걸 수도 있지만 개인적으로는 Mock이 Stub을 대체할 수 있다고 본다. (내가 배운)TDD에 의한다면 TestCase를 만드는 것이 선행이 되며 에러가 발생하는 Class의 작성이 시작이기 때문에 class의 method단위의 테스트가 용이한 Mock를 활용하는 것이 더 TDD스럽지 않나 생각이 든다. 

사실 Framework을 사용하게 되면 정말 간단하다. Mock 객체를 만드는 것은 소스 한줄이면 되고 또한 해당 mock 객체의 method가 return하는 값을 사용자가 정의하는 것 역시 한줄이면 된다.  다만 10개의 class가 하나의 비지니스를 담당한다고 했을때 잘 설계 및 구현 되었다고 할지라도 10개의 단위테스트가 성공하는 것이 하나의 비지니스 성공을 보장할 수 있을 까란 생각도 든다.

아직 경험이 미천해서 그런것이겠지.................ㅇㅇ? 

참고
JUnit In Action
http://msdn.microsoft.com/ko-kr/magazine/cc163358.aspx  
신고

'01.Java' 카테고리의 다른 글

run Hadoop Mapreduce Job Remotely(Cluster)  (0) 2012.03.13
Exception Handling vs. Error Logging  (0) 2012.02.14
JUnit Test. 그리고 Stub, Mock  (0) 2011.12.27
java.io.FilenameFilter 활용  (0) 2011.08.09
[예시] byte단위로 잘라서 String 만들기  (0) 2010.11.25
Method Class  (0) 2010.06.07
Posted by Stewie


티스토리 툴바