2011년 6월 13일 월요일

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

좋은 테스트의 특징
1. 자동적 : 단위 테스트는 자동적으로 실행되어야 한다. 새로운 모듈이 시스템에 통합되거나 추가될 때마다 추가된 기능 부분을 테스트하면서 그 이전에 있던 기능 부분들도 다시 테스트 하는 것(일관성 있는 회귀 테스트)은 아주 지루하고 힘든 일이 될 수 있다.
2. 철저함 : 좋은 단위 테스트는 문제가 될 수 있는 모든 것을 테스트 한다. 극단적인 경우에는 코드의 모든 줄 하나하나, 코드가 취할 수 있는 모든 가능한 분기, 코드가 일으키는 모든 예외 등을 테스트 대상으로 삼을 수 있다.
3. 반복 가능 : 모든 테스트는 다른 테스트들로부터 독립적이어야 하는 것과 마찬가지로, 환경으로부터도 독립적이어야 한다. 모든 테스트가 어떤 순서로든 여러 번 반복 실행될 수 있어야 하고, 그때마다 늘 같은 결과를 내야 한다.
4. 독립적 : 테스트는 깔끔함과 단정함을 유지해야 한다. 확실히 한 대상에 집중한 상태여야 하며, 환경과 다른 개발자들에게서 독립적인 상태를 유지해야 한다.
5. 전문적 : 단위 테스트를 위해 작성하는 코드는 제품 코드와 마찬가지로 전문적 표준을 유지하면서 작성되어야 한다.
6. 테스트를 테스트하기 : 테스트 코드가 정확하다는 것을 확인하기 위해 다음의 두 가지를 확인한다.
- 버그를 고칠 때 테스트를 개선하기
- 버그를 집어넣어 테스트를 검증하기

프로젝트에서 테스트 하기
1. 테스트 코드를 어디에 둘 것인가? : 대상 코드와 테스트 코드를 같은 디렉토리에 놓는다면 대상 코드의 protected 멤버 변수와 메서드에 접근 할 수 있지만 디렉토리가 어질러 지는 단점이 있게 된다. 반면 다른 디렉토리(예를 들어 하위의 test디렉토리)에 둔다면 protected 멤버 변수와 메서드에 접근 하지 못하는 단점이 생긴다.
2. 테스트 예절 : 여러 사람들과 동시에 개발을 하게 된다면 CVS와 같은 버전 컨트롤러를 사용하게 될 것이다. 다른 사람의 테스트를 방해하지 않기 위해서는 다음과 같은 코드는 Check In하기 전에 확인해야 한다.
- 불완전한 코드
- 컴파일 되지 않은 코드
- 컴파일 되기는 하지만, 다른 코드를 망가뜨려서 컴파일 되지 않게 만드는 코드
- 대응하는 단위 테스트가 없는 코드
- 단위 테스트가 실패한 코드
- 자신의 테스트는 통과하지만, 시스템의 다른 테스트를 실패하게 만드는 코드
3. 테스트 빈도
- 새 메서드를 작성할 때마다
- 버그를 고칠 때 마다
- 성공적으로 컴파일할 때마다
- 버전 관리 시스템에 체크인 할 때 마다
- 끊임 없이 : 주기적으로 수행되어야 한다.
4. 테스트와 레거시 코드 : 코드가 합리적으로 잘 분리되어 있고 모듈화되어 있어서 필요한 모든 개별적 조각을 얻을 수 있는 정도라면, 단위 테스트를 꽤 쉽게 추가할 수 있다. 반대로, 그냥 모든 것이 뒤얽힌 진흙 덩이라면 상당한 부분을 재작성 하지 않는 한 테스트하는 일은 불가능에 가까울 것이다.

댓글 없음:

댓글 쓰기

블록체인 개요 및 오픈소스 동향

블록체인(block chain) 블록체인은 공공 거래장부이며 가상 화폐로 거래할때 발생할때 발생할 수 있는 해킹을 막는 기술. 분산 데이터베이스의 한 형태로, 지속적으로 성장하는 데이터 기록 리스트로서 분산 노드의 운영자에 의한 임의 조작이 불가...