납븐 테스트의 예시 ::
-
테스트를 사용하는 사람에거 어떤 정보도 주지 못하는 테스트
-
산발적으로 실패하는 테스트
-
어떤 가치도 증명하지 못하는 테스트
-
실행하는 데 오래 걸리는 테스트
-
코드를 충분히 커버하지 못하는 테스트
-
구현과 강하게 결합되어 있는 테스트
FIRST 원리 :: 위험을 피하는 테스트 작성
Fast
빠른 테스트는 코드만 실행하지만, 느린 테스트는 데이터베이스, 파일, 네트워크 호출처럼 외부 자원을 다루는 코드를 호출한다.
이처럼 느린 테스트의 실행시간은 수백, 수천 ms가 걸리기도 한다. 만약 단위 테스트 하나당 평균 200ms가 소요된다면 시스템 전체의 단위 테스트 2500개를 모두 실행하는 데만 8분 이상 기다려야 한다!!
느린 저장소 조회 대신 메모리상의 컬렉션을 사용하여 테스트하자. ( 느린 것에 의존하는 코드를 최소화)
Isolated
좋은 테스트는 작은양의 코드에 집중하여야 한다. 직접적, 간접적으로 테스트 코드와 상호작용하는 코드가 많아질 수록 문제가 발생할 소지가 늘어난다.
또한 좋은 테스트는 다른 테스트에 의존하지 않는다. 다른 테스트 코드에서 값비싸게 생성된 데이터를 재사용하고 싶은 마음이 들 수 있다. 하지만 그러면 테스트가 실패했을 때 무엇이 원인인지 알아내느라 훨씬 많은 시간을 소비하게 될 수 있다.
테스트 코드는 어떤 순서나 시간에 관계없이 실행할 수 있어야 한다.
Repeatable
좋은 테스트는 실행할 때마다 결과가 같아야 한다. 간헐적으로 실패하는 테스트를 신뢰할 수는 없는 법이다.
반복 가능한 테스트를 만드려면 통제할 수 없는 외부 환경의 항목들과 격리시켜야한다. 하지만 시스템은 불가피하게 통제할 수 없는 요소와 상호 작용하여야 한다. 예를 들어 현재 시간을 다루어야 하는 문제가 있을 수 있다. 이럴 때는 코드가 진짜 시간을 가진 것처럼 고정된 시간을 반환하는 Clock을 통해 가짜 Clock 객체를 넘겨서 테스트 할 수 있다.
Self-validating
좋은 테스트는 그 결과로 기대하는 것이 무엇인지 검증할 수 있어야 한다. 또한 스스로 검증 가능할 뿐 아니라 준비할 수도 있어야 한다. 즉, 테스트에 필요한 어떤 설정 단계든 자동화를 해야 한다. (그럼에도 불구하고 실행하는데 외부 설정이 필요하다면 Isolated 원칙을 위반한 것!!)
Timely
가능한 적절한 순간에 단위 테스트를 작성하고 사용하여야 한다. 오래된 코드보다는 새로운 코드, 그리고 말썽이 많고 역동적인 부분에 테스트를 집중하여야 한다.
