우선 미래에 다른 사람이 히트 카운터의 코드를 변경해서 다시 망가뜨릴 가능성이 남아 있다. 이 문제는 자동 테스트를 추가해서 히트 카운터가 방해를 받더라도 정상적으로 작동하는지 확인하게 하면 해결된다. 테스트가 잘 작동해서 문제가 발생할 때 개발자에게 경고 메시지를 보내게 한다. 이 정도면 되었을까?

아니다. 아직도 문제를 일으킬 위험 요소가 남아 있다.

다음으로 자신이 만들어둔 테스트가 유지 보수하기 쉬운지 확인해야 한다. 테스트의 유지 보수가 어려우면 개발자가 코드를 변경할 때 테스트도 너무 많이 달라져서 테스트 코드 자체가 수수께끼처럼 복잡해진다. 그러면 코드가 바뀔 때 거짓 긍정 신호_{false positive}를 반환하기 쉬워진다. 그 결과 나중에 테스트가 망가질 확률, 이 테스트를 다른 사람이 없애버릴 확률도 높아진다.

여기까지 오면 결국 누군가는 해당 문제를 다시 다루어야 한다. 그러므로 자신이 작성한 코드는 확실히 유지 보수하기 쉽게 만들어야 하고(32장 ‘테스트 철학’ 참고), 유지 보수가 어렵다면 다시 리팩토링해야 한다. 테스트 코드가 리팩토링을 통해 단순해졌는지 확인하려면 테스트 중 테스트 프레임워크나 시스템의 상태가 어떠한지 확인해보면 된다.

그 후에는 지속적 통합 시스템(또는 테스트 러너)에 대한 고민이 생길 수 있다. 정말 신뢰할 만한 시스템일까? 이 시스템이 망가져서 다른 사람이 내가 만든 테스트를 다시 살펴봐야 할 수도 있지 않을까? 이런 문제가 또 다른 조사 대상이 될 수 있다.