FIRST : 좋은 테스트 조건

• 빠르다 : 빠른 테스트는 코드만 실행한다. 느린 테스트는 데이터베이스, 파일, 네트워크 호출처럼 외부 자원을 다루는 코드를 호출한다. 테스트가 빠를수록 반복 가능하고 지속적인 리팩터링이 가능하므로 가능한 빠르게 만들어야 한다. 외부 자원에 의존하는 부분을 최소한의 메소드로 고립시키고, 다른 메소드는 외부자원을 이용해 받아오는 값을 매개변수로 받도록 수정한다. 즉 느린 자원에 대한 의존성을 줄인다. 테스트에서는 매개변수만 생성해서 넘기면 된다.
• 고립시킨다 : 순서나 시간에 관계없이, 느린 외부 자원에 의존하지 않고 실행되어야 한다.
• 반복 가능하다 : 실행할 때마다 결과가 같아야한다. 통제 불가능한 요소는 최대한 고립시키는 것이 좋은데, 어쩔 수 없이 소통해야하는 경우 목 객체를 만들어 사용한다. 현재 시간을 반환하는 메소드를 실행할 경우 Clock 목을 생성해 세터로 주입 → 현재 시간에 대한 의존성 끊기
• 스스로 검증 가능하다 : 테스트 결과를 성공 혹은 실패로 쉽게 파악할 수 있어야 한다. 시스템이 변경될 때마다 테스트를 자동으로 실행해야한다. Infinitest나 CI 도구에 테스트 절차를 통합할 수 있다.
• 적시에 사용한다 : 코드를 작성한 뒤 바로 테스트해야한다. 충분한 테스트가 없을 때 코드 통합을 거부하는 도구나 시스템을 사용한다.

Right-BICEP : 무엇을 테스트할 것인가?

• 결과가 올바른가 : 행복 경로 테스트는 코드가 정상적으로 동작할 때, 그것을 확인할 수 있어야 한다. 요구사항이 바뀌면 그때 테스트를 개선하면 된다. 이때 단위 테스트는 변경이 발생하기 전까지 코드가 어떻게 동작하는지 알 수 있다.
• 경계 조건이 맞는가 : 결함은 모서리 사례에서 발생하므로 테스트로 처리해야한다. CORRECT에서 더 자세히 다룬다. 주로 null이나 0 검사, 수치적 오버플로, 일관성 없는 값, 잘못된 양식의 데이터, 가정과 다르게 동작할 수 있는 가능성을 검사한다. 오류가 치명적이라면 시스템 코드에서 잡아 예외를 던지는 것이 좋다.
• 역 관계를 검사할 수 있는가 : 제곱근을 구하는 메소드라면 제곱근 * 제곱근 = 원래수를 검사하거나, 교차 검사 수행(프로필에 Answer을 추가하고, 추가한 앤써의 아이디를 검증)
• 다른 수단을 활용해 교차 검사를 할 수 있는가 : 모든 요소를 더하고 균형이 맞는지 확인, 대출된 도서의 수와 선반에 있는 도서 수를 합치면 도서의 총 수량이 됨
• 오류 조건을 강제로 일어나게 할 수 있는가 : 유효하지 않은 매개변수에 대해서는 경계조건으로 쉽게 달성할 수 있다. 하지만 메모리, 디스크, 네트워크, 시스템 로드, 시간, 해상도 등 시스템과 관련된 문제들은 시뮬레이션하기 어려운데, 아마 목 객체로 이 상황이 발생한 척 할 수 있을 듯?? 10장 참고
• 성능 조건은 기준에 부합하는가 : 성능 병목 지점을 개선할 때, 최적화 시도는 실제 데이터를 기반으로 해야하며 추측을 기반으로 하면 안된다. 시간이나 메모리 등을 기준으로 최적화를 시도할 수 있다. 단위 성능 측정은 변경 사항이 발생할 때 기준점으로 활용하는 것이 좋다. 개선 전후의 테스트 성능을 비교하고 교체하는 것이 좋다.