Archive for August 2010
[eclipse plug-in] moreunit – 테스트 유닛은 어디에?
moreunit은 작성중인 클래스에 테스트 코드가 작성되어 있는지를 시각적으로 보여주는 플러그인이다.
해당 플러그인에 대한 자세한 설명은
http://moreunit.sourceforge.net/index.html
에서 확인할 수 있다.
설치는, 직접 다운로드하여 플러그인 디렉토리에 풀어주거나,
이클립스 플러그인 설치 메뉴로부터,
http://moreunit.sourceforge.net/update-site/
를 등록하여 다른 플러그인 설치 과정과 동일하게 설치하면 된다.
본인의 경우, 별다른 기본 설정없이도 작성중인 클래스에 대해 테스트 클래스를 찾아 보여주었는데,
설정이 동작하지 않는다면 properties context menu로부터 세부 설정이 가능하다.
동작시의 화면은 moreunit의 공식사이트에 있는 것과 별 차이가 없다.
직접 테스트해본 화면은 다음과 같다.
우선, 아래 그림은 moreunit을 설치하기 전의 파일 구성이다.
이제 설치를 완료하고 나면, 똑같은 파일리스트에 빨간 동그라미를 표시한 것과 같이 오른쪽 상단에
녹색마크가 표시된다. 이는 해당 클래스에 테스트케이스가 작성되어 있음을 나타낸다.
표시가 생긴 임의의 클래스를 살펴보면, 테스트 케이스가 작성된 메소드에는 메소드의 좌측 라인에 마찬가지로
테스트케이스가 있음을 나타내는 마크가 보인다.
해당 라인에서 마우스 오른쪽 버튼을 클릭하여 context메뉴를 통해 이동하거나, 단축키 ctrl + j를 누른다면,
해당 메소드의 테스트케이스로 직접 이동할 수 있다.
back and forth about something ~에 대해 왔다갔다(갈팡질팡) 하다
“아이폰 살거야? 아니면, 안드로이드 폰 살거야?” 라고 누군가 묻는다면,
I am back and forth about that.
나도 그 점이 왔다갔다 해
at least ~ vs. ~ at least – at least가 문장 중 위치에 따라 뜻이 달라진다?
at least는 흔히 알기로, 수식하려는 말 앞에 오면 “적어도 ~”을 뜻한다.
“at least A” 는 “적어도 A'”라고 쓰는 것이 일반적이다.
그런데, at least가 문장 맨 뒤에 온다면 조금 다른 의미로 쓰인다고 한다.
Could you lend me at least $10?
– 최소(적어도) 10달러 빌려줄래?
그런데, 다음 문장을 보자.
Could you lend me $10 at least?
– 다만 10달러라도 빌려 줄 수 있어?
– 10달러라도 좋으니 빌려줄 수 있어?
라는 뜻이 된다.
수식어의 위치에 따라, 다른 뉘앙스를 나타낼 수 있으니 유의하자.
JUnit에서의 예외 인식
JUnit에서 작성한 어떤 테스트케이스가 Exception을 던지고,
그 Exception이 던져진 것이 맞는 상황임을 검증하고자 한다면,
JUnit3에서는
public void testDivideByZeroV3() {
try {
int a = 3/0;
} catch(Exception e) {
assertSame(e.getClass(), ArithmeticException.class);
}
}
반면, JUnit4에서는
@Test(expected=ArithmeticException.class)
public void testDivideByZeroV4() {
int a = 3/0;
}
예외 처리만으로도 JUnit4가 JUnit3보다 간략하다는 것을 확인할 수 있다.
JUnit으로 test coverage를 높이는 습관
“우리나라 정서상 어렵다, 현실에 맞지 않다”는 말들을 하기도 하고, 듣기도 한다.
Rod Johson이 그의 저서 “Expert one-on-one J2EE Design and Development”에서
XP 기법을 소개하면서, 그 기법의 모든 것을 따르지는 않더라도 테스트 지향 개발 방법은 바람직하다고 하였다.
테스트에 대한 XP의 기법은,
- 코드를 작성하기 전에 먼저 테스트 코드를 작성하자
- 모든 코드는 단위 테스트 코드를 가져야 하고, 각 단위 테스트는 자동으로 실행될 수 있어야 한다.
- 버그가 발견되면 버그를 고치기에 앞서, 버그를 다시 재현해 내는 테스트 케이스를 정의한 후에 고쳐야 한다.
테스트 코드를 먼저 작성하는 것이 더 유용하다는 관점에 대해서는,
- 테스트 문서는 스펙 문서에 근거할 뿐만 아니라, 부가적인 정보를 제공한다.
- 클래스나 컴포넌트 자체로만으로는 불확실한 내용이 테스트에서는 명확해진다. (사용처나 목적을 분명히 알고 작성할 것이므로)
- 사실, 코드를 모두 작성한 후에 별도로 테스트 코드를 작성하는 것이 훨씬 어렵다.
그러므로, 한 메소드씩 작성하되, 코드-테스트코드의 순서가 아니라, 반대인 테스트코드-코드의 순서로 작성해 나가자.
Rod Jonhson은 test 메소드의 이름을 다음과 같이 작성하도록 권고한다.
예를 들면,
private void testCommaDelimitedListToStringArrayLegalMatch(String[] components); public void testCommaDelimitedListToStringArrayMatchWords(); public void testCommaDelimitedListToStringArraySingleString();
단순히 테스트의 coverage를 높이기 보다는, 테스트의 메소드 이름만으로도 테스트의 성격을 알 수 있도록 작성해 보자.
테스트내에서도 반복되는 테스트의 경우 private로 작성하고, 이를 활용하자.
위의 예는,
commaDelimitedListToStringArray(String s);
를 테스트한 예이다.
그리고, 테스트코드도 꾸준히 버전 관리를 해야 한다.
everydayminder 