아는 사람 블로그 링크를 통해 보게 되었다.
Junit 4 로 뛰어들기

내가 예전에 써둔 글과 비슷한 범위의 내용을 다루었다.
JUnit 3.8에서 JUnit 4, TestNG 활용으로

하지만, 정성스레 만든 기사니까 설명은 더 충실하다. 물론.. ^^

번역을 하고 있는 입장에서 다른 사람 번역에 대해 왈가왈부하는 것은 조심스러운 일이지만 관심이 전보다 더 간다.

annotation을 주석으로 번역한 것은 조금 갸웃거리게 했다. 한편, fixture는 픽스쳐로 되어 있다. 하지만, annotation을 주석으로 번역해도 기사 이해에는 전혀 무리가 없다.

글 내용을 살펴보면 짧은 아티클 하나로 JUnit 4를 대략 살펴볼 수 있을 좋은 글이다.
다만, JUnit 이나 단위 테스트에 대해 기본적으로 알고 있어야 한다.

단위 테스트의 "단위"에서 언급한 것에 더하여 팀 내에서는 단위 테스트에 대한 인식을 공유할 필요가 있다.

'어디까지가 단위 테스트인가?'라는 물음을 가지고 100분 토론을 한다면 답은 나오지 않을 것 같다. :) 이런 류의 일들은 지적인 유희에 지나지 않는다. 인식의 공유가 목적이라면 단위 테스트에 대한 정의가 팀내에서 경험이나 IQ(?)가 제일 낮은 사람도 이해할 만큼 쉬워야 하고, 충분히 유용해야 한다.

링크만 보관하던 글을 오늘에야 읽었는데 쌈빡한 정리를 제공한다: A Set of Unit Testing Rules

A test is not a unit test if:

It talks to the database

It communicates across the network

It touches the file system

It can't run at the same time as any of your other unit tests

You have to do special things to your environment (such as editing config files) to run it.

Rod Johnson의 그의 많은 저서에서 수도 없이 강조하던 POJO 기반 개발의 장점이다. 테스트의 용이성. EJB 중심 개발은 살짝 오바하면, 사실상 TDD가 불가능하다고도 할 수 있다.

위의 법칙(?)을 어떻게 활용할 것인가?

'데이터베이스에 접근하는 것은 통합 테스트로 분류하자.'

영양가가 떨어지는 결론의 전형적인 예를 들어봤다.

좀 더 의미 있는 결정을 끌어내보자. 일단, 단위 테스트에서 최대한 위에 언급한 사항을 피할 수 있는 방법을 찾는 것이다. 토비님이 JUnit Recipes: Practical Methods for Programmer Testing 책을 추천해주었는데, 매우 좋은 기법들이 즐비하다. 즐비한 만큼 두껍지만... :)

또 하나의 예를 들자면, Test Suite 같은 것을 구성할 때, 위의 내용이 포함되는 것과 그렇지 않은 "진정한" 단위 테스트를 구분해놓는 것이다. 그렇게 되면 시간이 덜 걸리는 단위 테스트는 자주 할 수 있고, 시간이 좀 걸리는 통합 테스트 성격의 것들은 자판이 노는 시간에 할 수 있다. 밥 먹으러 가면서 걸어둔다거나, 야간에 걸어두고 퇴근하거나... (일부 Continuous Integration을 수행하는 환경에 대해서는 논외로 한다.)

A Set of Unit Testing Rules의 후미에서는 테스트 대상이 되는 애플리케이션 코드를 플랫폼(OS, 벤더의 제품 등)에서 분리하여 테스트 하는 것의 추가적인 이점을 얘기해준다. 문제가 발생할 때 애플리케이션 로직의 문제인지, 플랫폼의 문제인지, 혹은 통합의 문제인지가 분명해진다. 한편, TDD 환경이라면 이러한 과정을 통해 자연스럽게 결합도(coupling)이 낮아질 가능성도 높다.