오늘도 읽은 내용 중 정리하고 싶은 부분 정리해본다.

• 데이터베이스처럼 복잡한 리소스를 이용해 테스트해야 하는 경우 mock 객체를 이용하면 좋다. 다만 mock 객체가 진짜 객체와 동일하지 않게 동작할 위험이 새로 발생하므로 주의가 필요하다.
• 모든 에러 상황을 다 테스트하는 것은 현실적으로 어렵다. 작동하길 원하는 부분에 대해서만 하면 된다.
• 혼자 프로그래밍 하고 있다면, 테스트가 실패하는 상황에서 개발을 끝내는게 좋다. 그래야 다음에 다시 개발할 때 어디서부터 시작할지 헤매지 않을 수 있다. 실패한 테스트에서 출발해 그 테스트를 성공시키기 위한 구현과 리팩토링을 해나가면 된다.
• 함께 개발하고 있다면 반대로 테스트가 모두 성공한 지점에서 코드 체크인을 해야 한다. 이것은 상대방에 대한 예의기도 하다.
• 하나의 구체적인 예에서 시작해 일반화하면 쓰잘데기 없는 고민으로 혼란스러워지는 것을 피할 수 있다.
• 테스트를 통과하기 위한 “가짜 구현"을 할 때, 명백한 구현이 떠오른다면 바로 그렇게 구현해도 된다.
• 명백한 구현, 좋은 구현만 하려고 한다면 자신에게 너무 높은 완벽주의 기준을 제시하게 되어 오히려 개발을 어렵게 한다. 제대로 동작하면서 동시에 깨끗한 코드를 한번에 짜려는 것은 욕심일 수 있다. 먼저 돌아가게 하고 나중에 깨끗하게 하자.
• 테스트에 공통적으로 사용되는 객체를 생성할 때는 매번 생성해 사용할 수도 있고 setUp이나 tearDown에서 구현할 수도 있다. 중복을 제거하면 반복 코드 작성 시간이 줄어들고, 인터페이스 변경이 용이하지만 가독성이 떨어지는 단점이 있다.
• 각 테스트의 목적 중 하나는 테스트가 실행되기 전과 실행 후 외부세계가 동일하게 유지되도록 하는 것이다.
• 테스트는 읽기 쉬워야 한다. 최종 목표에 도달할 수 있는 가장 짧은 코드를 짜야 한다.
• 코드에 중복이 나타나는 순간 컴포지트 패턴을 도입해보는 것도 좋다.