TDD xUnit 예시

2. xUnit 예시

xUnit으로 가는 첫걸음

테스트 케이스를 작성하기 위해 사용할 프레임워크를 테스트하기 위한 테스트 케이스를 작성해야 한다

일단 하드코딩한 다음에 상수를 변수로 대체하여 일반성을 이끌어내는 방식

테이블 차리기

테스트를 작성하다보면 공통된 패턴

1. 준비(arrange) - 객체를 생성

2. 행동(act) - 어떤 자극을 줌
3. 확인(assert) - 결과를 검사

준비 단계는 여러 테스트에 걸쳐 동일한 경우가 있다

만약 이 패턴이 서로 다른 스케일에서 반복된다면 테스트를 위해 새로운 객체를 얼마나 자주 생성해야 하는가 하는 문제에 직면

이 때 두 가지 제약이 상충

• 성능 - 우린 테스트가 될 수 있는 한 빨리 실행되길 원한다. 여러 테스트에서 같은 객체를 사용한다면, 객체 하나만 생성해서 모든 테스트가 이 객체를 쓰게 할 수 있을 것이다.
• 격리 - 우린 한 테스트에서의 성공이나 실패가 다른 테스트에 영향을 주지 않기를 원한다. 만약 테스트들이 객체를 공유하는 상태에서 하나의 테스트가 공유 객체의 상태를 변경한다면 다음 테스트의 결과에 영향을 미칠 가능성이 있다.

테스트 커플링은 만들지 말 것!

테스트를 작성하는 데 있어 간결함이 성능 향상보다 더 중요하다

단순화하기 위해 setUp()을 사용

뒷정리하기

setUp()에서 외부 자원을 할당하는 경우도 있음

테스트가 계속 서로 독립적이길 바란다면 외부 자원을 할당받은 테스트들은 작업을 마치기 전에 tearDown() 메서드 같은 곳에서 자원을 다시 반환할 필요가 있다.

셈하기

실패 처리하기

얼마나 달콤한지

…

xUnit 회고

이미 구현되어 있더라도 xUnit을 직접 구현해볼 만한 두 가지 이유

• 숙달: xUnit의 정신은 간결함에 있다. 직접 만들어 사용하면 숙달된 도구를 쓰는 느낌을 받게 될 것
• 탐험: 그 언어로 프로그래밍하면서 접하게 될 많은 기능을 한 번씩 경험해보게 됨

참고

• 테스트 주도 개발(http://www.yes24.com/Product/Goods/12246033)