본문 바로가기

Extremely Agile/TDD17

FitNesse를 활용한 프로그래머 테스트 최근에 Fit이라는 테스팅 프레임워크에 대한 책을 번역했습니다. 이 책의 초고는 지금 베타리더분들께 가 있는데, 조만간 출판사로 넘길 수 있지 않을까 생각합니다. 기다리시는 분들께 다시 한번 사과말씀 드립니다. 아무튼 오늘 하려는 이야기는 그게 아니고... FitNesse라는 프레임워크가 있습니다. 이 프레임워크는 Fit을 Wiki 형태로 사용할 수 있게 해주는 좋은 도구입니다. 이 도구를 처음 접하고, 어떻게 써먹으면 좋을까 고민을 좀 했습니다. 제가 회사에서 맡은 일이 주로 네트워크 프로토콜 스택을 구현하는 일이라, 거기에 적용할 방법이 없을까 생각해봤습니다. 아니, 처음부터 그렇게 생각한 건 아닙니다. 첨엔 삽질부터 시작했죠. 그 삽질이 어떤 과정으로 진행되었는지 살펴보자면 대략 다음과 같습니다. .. 2009. 5. 14.
FindBugs: 코드의 정적 분석을 통한 버그 탐색 FindBugs라는 프로젝트가 있습니다. 코드의 정적 분석을 통해 코드에 내재된 버그를 찾는 솔루션을 만드는 프로젝트입니다. 많은 개발자들이 정적 분석을 통한 버그 탐색 방법을 도외시하는 경향이 있습니다만, 개발자들도 사람이니 '바보같은' 실수를 저지르게 되어 있기 마련이라는 점을 감안한다면, 짝 프로그래밍이나 코드 리뷰가 버그를 많이 줄여준다고 하더라도 그런 미련한 버그들이 코드에 뒤섞이는 것을 100% 방지할 수는 없습니다. 정적 분석 (static analysis) 방법이 그런 버그를 찾을 수 있게 도와준다면, 사용하지 않을 이유는 없어 보이는데요. 다행히 FindBugs 프로젝트는 Eclipse나 Netbeans 같은 IDE상에서도 사용할 수 있을 정도로 성숙되었고, 많은 분들이 쓰고 계십니다. .. 2008. 11. 4.
jMock을 이용한 남의 코드 테스팅 (3) 앞서 남이 짠 클래스 코드를 어떻게 리팩토링하면 jMock을 통해 테스트하기가 좀 더 쉬워지는지를 살펴봤습니다. 그런데 현실 세계의 클래스들이 전부 그렇게 간단하게 만들어져 있으면 문제가 쉬운데, 실제로 테스트를 진행하다보면 그렇지 않은 경우를 종종 만나게 됩니다. 가장 골치아픈 경우 중 하나는, 생성자 안에 해당 클래스의 비즈니스 로직(?)이 들어가 있는 경우죠. 그러니까 좀 돌려서 말하면, 클래스의 생성자 코드 안에 테스트해야하는 알고리즘의 일부가 들어가 있는 경우입니다. 이 알고리즘이 대상으로 하는 객체들 중 하나를 Mock 객체로 만들어 테스트해야 한다면, 상황은 간단히 풀리지 않습니다. 다음 코드를 보시죠. class Foo { public Foo() { ... bar.doSomething();.. 2008. 11. 4.
jMock을 이용한 남의 코드 테스팅 (2) 그러면 오늘은 jMock을 이용해 남의 코드를 테스팅하는 과정을 한번 살펴보겠습니다. 정답이라고 할 수는 없고, 저 개인적인 경험에 따른 것이니, 참고 정도 하시면 좋을 것 같습니다. 남의 코드를 테스팅할 때 중점적으로 고려한 사항은 다음과 같습니다. 1. 남의 코드의 인터페이스는 손대지 않는다. 2. 남의 코드의 주 알고리즘은 손대지 않는다. 물론 2는 어쩔 수 없이 손대야 할 경우도 생기긴 합니다만, 가급적 그러지 않는 것이 정신건강상 이롭습니다. 왜 그런지는 아마 여러분들도 잘 아실 거라 생각합니다. 그러면 이제 실제 사례를 살펴보겠습니다. ConnectionManager라는 클래스입니다. 이 클래스는 대략 다음과 같은 골격을 가지고 있습니다. public class ConnectionManager.. 2008. 11. 3.