테스트 지향 프로그래밍 with JUnit - 4

좋은 테스트의 특징

1. 자동적 : 단위 테스트는 자동적으로 실행되어야 한다. 새로운 모듈이 시스템에 통합되거나 추가될 때마다 추가된 기능 부분을 테스트하면서 그 이전에 있던 기능 부분들도 다시 테스트 하는 것(일관성 있는 회귀 테스트)은 아주 지루하고 힘든 일이 될 수 있다.

2. 철저함 : 좋은 단위 테스트는 문제가 될 수 있는 모든 것을 테스트 한다. 극단적인 경우에는 코드의 모든 줄 하나하나, 코드가 취할 수 있는 모든 가능한 분기, 코드가 일으키는 모든 예외 등을 테스트 대상으로 삼을 수 있다.

3. 반복 가능 : 모든 테스트는 다른 테스트들로부터 독립적이어야 하는 것과 마찬가지로, 환경으로부터도 독립적이어야 한다. 모든 테스트가 어떤 순서로든 여러 번 반복 실행될 수 있어야 하고, 그때마다 늘 같은 결과를 내야 한다.

4. 독립적 : 테스트는 깔끔함과 단정함을 유지해야 한다. 확실히 한 대상에 집중한 상태여야 하며, 환경과 다른 개발자들에게서 독립적인 상태를 유지해야 한다.

5. 전문적 : 단위 테스트를 위해 작성하는 코드는 제품 코드와 마찬가지로 전문적 표준을 유지하면서 작성되어야 한다.

6. 테스트를 테스트하기 : 테스트 코드가 정확하다는 것을 확인하기 위해 다음의 두 가지를 확인한다.

- 버그를 고칠 때 테스트를 개선하기

- 버그를 집어넣어 테스트를 검증하기

프로젝트에서 테스트 하기

1. 테스트 코드를 어디에 둘 것인가? : 대상 코드와 테스트 코드를 같은 디렉토리에 놓는다면 대상 코드의 protected 멤버 변수와 메서드에 접근 할 수 있지만 디렉토리가 어질러 지는 단점이 있게 된다. 반면 다른 디렉토리(예를 들어 하위의 test디렉토리)에 둔다면 protected 멤버 변수와 메서드에 접근 하지 못하는 단점이 생긴다.

2. 테스트 예절 : 여러 사람들과 동시에 개발을 하게 된다면 CVS와 같은 버전 컨트롤러를 사용하게 될 것이다. 다른 사람의 테스트를 방해하지 않기 위해서는 다음과 같은 코드는 Check In하기 전에 확인해야 한다.

- 불완전한 코드

- 컴파일 되지 않은 코드

- 컴파일 되기는 하지만, 다른 코드를 망가뜨려서 컴파일 되지 않게 만드는 코드

- 대응하는 단위 테스트가 없는 코드

- 단위 테스트가 실패한 코드

- 자신의 테스트는 통과하지만, 시스템의 다른 테스트를 실패하게 만드는 코드

3. 테스트 빈도

- 새 메서드를 작성할 때마다

- 버그를 고칠 때 마다

- 성공적으로 컴파일할 때마다

- 버전 관리 시스템에 체크인 할 때 마다

- 끊임 없이 : 주기적으로 수행되어야 한다.

4. 테스트와 레거시 코드 : 코드가 합리적으로 잘 분리되어 있고 모듈화되어 있어서 필요한 모든 개별적 조각을 얻을 수 있는 정도라면, 단위 테스트를 꽤 쉽게 추가할 수 있다. 반대로, 그냥 모든 것이 뒤얽힌 진흙 덩이라면 상당한 부분을 재작성 하지 않는 한 테스트하는 일은 불가능에 가까울 것이다.