[18장] xUnit으로 가는 첫걸음
테스트 툴을 만드는 과정에서 만들어지는 테스트 툴 자체를 사용한다는 것은 스스로 자신의 뇌를 수술하는 것과 비슷할 것 같다. 때때로 괴상해지기도 할 것이다.
테스트 케이스를 만들고 테스트 메서드를 실행할 수 있어야 한다.
우린 테스트 케이스를 작성하기 위해 사용할 프레임워크를 테스트하기 위한 테스트 케이스를 작성해야 하는 것이다. 아직 프레임워크가 없기 때문에 첫 번째 작은 단게는 수동으로 검증해야 할 것이다.
<테스트 프레임워크에 대한 할일 목록>
-테스트 메서드 호출하기
-먼저 setUp 호출하기
-나중에 tearDown 호출하기
-테스트 메서드가 실패하더라도 tearDown 호출하기
-여러 개의 테스트 실행하기
-수집된 결과를 출력하기
테스트 메서드가 호출되면 true, 그렇지 않으면 false
테스트 메서드 안에 플래그를 설정하는 테스트 케이스가 있다면, 그 테스트 케이스가 실행된 이후에 플래그를 인쇄해 볼 수 있고, 그러면 그게 맞는지 아닌지 확인해 볼 수 있다. 일단 한 번만 수동으로 검증하면 앞으로는 이 과정을 자동화할 수 있다.
부트스트랩 테스트를 위한 전략이 있다. 플래그를 가지고 있는 테스트 케이스를 만들 것이다. 테스트 메서드가 실행되기 전에는 플래그가 false인 상태여야 한다. 테스트 메서드가 플래그를 설정할 것이고, 테스트 메서드가 실행된 후에는 플래그가 true여야 한다.
리팩토링의 일반적인 패턴. 하나의 특별한 사례에 대해서만 작동하는 코드를 가져다가 다른 여러 사례에 대해서도 작동할 수 있도록 상수를 변수로 변화시켜 일반화하는 것이다.
[정리]
-일단 하드코딩을 한 다음에 상수를 변수로 대체하여 일반성을 이끌어 내는 방시긍로 기능을 구현했다.
-플러거블 셀렉터(Pluggable Selector)를 사용했다. 플러거블 셀렉터는 정적 코드 분석을 어렵게 만든다.
-테스트 프레임워크를 작은 단계로만 부트스트랩했다.
[19장] 테이블 차리기
<테스트 작성 패턴(3A)>
1.준비(arrange)
2.행동(act)
3.확인(assert)
테스트를 위해 새로운 객체를 얼마나 자주 생성해야 하는가. 두가지 제약이 상충
-성능 : 우린 테스트가 될 수 있는 한 빨리 실행되길 원한다. 객체 하나만 생성해서 모든 테스트가 이 객체를 쓰게 할 수 있을 것이다.
-격리 : 우린 한 테스트에서의 성공이나 실패가 다른 테스트에 영향을 주지 않기를 원한다. 만약 테스트들이 객체를 공유하는 상태에서 하나의 테스트가 공유 객체의 상태를 변경한다면 다음 테스트의 결과에 영향을 미칠 가능성이 있다.
테스트 사이의 커플링은 확실히 지저분한 결과를 야기한다.
테스트가 실행되는 순서가 중요한 경우가 있다.
테스트 커플링을 만들지 말 것.
[정리]
-일단은 테스트를 작성하는 데 있어 간결함이 성능 향상보다 더 중요하다고 생각하기로 했다.
댓글