링크1 : 출처
Re: [질문]TDD에관해서 - Junit테스트 방식
먼저 웹 어플리케이션의 액션을 테스트하신다면 두 가지 방법이 있습니다.
하나는 웹 어플리케이션을 디플로이하고 HttpUnit 같은 웹 어플리케이션 테스팅 프레임워크
를 이용하여 테스팅하는 방법입니다. 다른 하나는 Action 개체에 제공되는 개체들을
MockObject 로 만들어서 테스팅하는 방법입니다. 스트러츠는 잘 알려진 프레임워크이므로
비슷한 것이 있지 않을까 싶지만 자세히는 모르겠습니다.
마지막으로 TDD 의 잇점은 TDD 로 작성된 어플리케이션의 경우 테스트 커버리지가 거의
100%에 육박한다는 점입니다. 즉, 테스트 코드가 대상 코드의 거의 모든 수행 경로를
테스트한다는 것이죠. 따라서 테스트 커버리지가 80%일 경우 테스트를 전부 통과하면
그 프로그램이 버그가 하나도 없을 가능성이 80% 라고 볼 수도 있겠죠? 만약 커버리지가
10% 라면...? 전혀 믿을만하지 못하겠죠? 이런 커버리지를 측정하는 도구도 있습니다.
테스트 커버리지 툴이라고 하는데요. 괜찮은 걸로는 Clover 나 EMMA 가 있습니다.
Clover 가 상용이고 성능이나 편의성 면에서 최고지요.
TDD 를 했을 경우 잇점은, 리팩터링의 sideeffect 를 없애 준다는 점입니다. 여차저차
해서 리팩터링은 많이 수행해야 하게 되었는데, 리팩터링 후에도 어플리케이션의 동작은
같아야 할 경우가 있죠? 이럴때 테스트가 잘 갖춰져 있다면 걱정이 없습니다.
또 유닛 테스트가 잘 되어 있다면 기계가 매번 테스트해 주므로 사람이 매번 테스트할 때
의 어떤 사유에서든지간의 테스트의 누락이 발생할 수 없습니다.
마지막으로 테스트 케이스가 잘 갖춰져 있을 경우 Continuous Integration 에 준비가 된
것으로 생각할 수 있습니다. CI 는 각 컴포넌트에 대한 유닛 테스트 및 전체 컴포넌트
를 통합하여 수행하는 통합 테스트를 주기적으로 수행하는 행위입니다. (엄밀히 말하면
빌드를 수행하는 것입니다만, 빌드 과정에 테스트가 포함됩니다.) 수명에서 수십, 수백
명의 개발자가 함께 작업하는 프로젝트가 있다고 생각해 봅시다. 이 경우 소스 코드
저장소 서버를 운영하고 있을 것이고, 누구나 그곳에 체크인을 할 수 있습니다.
CI 툴들은 이 저장소에서 주기적으로 소스 코드를 체크아웃해 빌드 및 테스트를 수행해
그것에 대한 리포팅을 하게 됩니다. 만약 CI 를 두시간 마다 한번씩 한다면 어떻게 될까요?
만약 최근 CI 에서 갑자기 테스트가 실패하게 되었다면 마지막 두 시간 사이에 체크인한
코드들을 검수하면 금방 문제가 해결되게 되겠죠? 정말 막강한 기능이 아닐 수 없죠.
어떤 개발 조직에서는 CI 가 성공하면 파란불이, 아니면 빨간불이 켜지는 램프를 같이
사용하여 효과를 극대화한다고 합니다.
쉽게 말해 TDD 는 프로세스입니다.
1. 소스 코드 저장소를 갖추고 모두가 서로의 코드를 공유하고 있나요?
2. 테스트 커버리지를 가능한 한 높게 유지하고 있나요?
3. CI 를 통해 단위 및 통합 테스트의 장점을 최대한 활용하고 있나요?
이 세 단계중 한 단계를 넘어갈 때마다 TDD 의 강점이 드러나는 것이라고 생각합니다.
그러니까, TDD 는 Agile Development 와 밀접한 관련이 있다고 할 수도 있겠네요.
--
what we call human nature is actually human habit.
--
http://gleamynode.net/"
