SqueakByExample:7.3
무엇이 좋은 테스트를 만들까요?
좋은 테스트 작성은 연습으로 가장 쉽게 학습될 수 있는 기술입니다. 최대의 유익을 얻게 될 테스트들의 속성을 함께 살펴봅시다.
- 테스트들은 반드시 반복 가능해야 합니다. 여러분은 여러분이 원하는 만큼 테스트들을 반복할 수 있어야 하며 항상 동일한 답을 얻을 수 있어야만 합니다.
- 테스트들은 사람의 개입 없이 실행되어야만 합니다. 여러분은 밤에도 테스트들을 실행할 수 있어야만 합니다.
- 테스트들은 반드시 스토리를 말해야 합니다. 각 테스트는 한 조각의 코드의 한 측면을 반드시 담당해야만 합니다. 테스트는 시나리오로서 기능하여, 여러분 또는 다른 사람이 기능의 조각(a piece of functionality)을 이해하기 위해 읽을 수 있어야만 합니다.
- 테스트들은 반드시 테스트들이 다룰 수 있는 기능의 빈도보다 적게 변경 빈도(a change frequency)를 갖아야 합니다: 여러분은 자신의 어플리케이션을 수정할 때마다 모든 여러분의 테스트들을 변경하기를 원하지 않을 것입니다. 이것을 이루는 한가지 방법은 여러분이 테스트할 클래스의 공공 인터페이스들(the public interfaces)에 기초하여 테스트들을 작성하는 것입니다. 만약 여러분이 테스트가 필요할 만큼 메소드가 충분히 복잡하다고 느끼실 경우, 개별적(private) “helper”를 위한 테스트를 작성하는 것은 괜찮지만, 여러분이 좀더 나은 실행법을 생각해 내었을 때, 그러한 테스트들은 변경될 수 있거나 완전히 버릴 수도 있다는 것을 반드시 염두 해두셔야 합니다.
property(3)의 결과는 테스트들의 숫자가 반드시 테스트된 기능들의 숫자와 비례해야만 합니다: 시스템의 어떤 측면을 변경시키는 것은 모든 테스트들을 파괴하지 않고 오직 제한된 숫자만을 파괴해야 합니다. 이것은 중요합니다. 그 이유는 100 개의 테스트의 실패는 10개의 테스트 실패보다 훨씬 더 강한 메시지를 보내기 때문입니다. 그럼에도 불구하고, 이 이상(ideal)을 성취하는 작업이 항상 불가능한 것만은 아닙니다: 특별히, 변경사항이 오브젝트의 초기화를 깨뜨리거나 테스트의 셋업(set up)을 깨뜨리면, 모든 테스트를 실패로 이끌 가능성이 높습니다.
eXtream 프로그래밍은 코드를 작성하기 전에 테스트를 작성할 것을 주장합니다. 이것은 아마도 소프트웨어 개발자로서의 우리의 깊은 본능에 배치될 수 있습니다. 우리는 모두 이렇게 말할 수 있을 것입니다: 계속하고 시도해! 우리는, 코드가 우리가 무엇을 코딩하기 원하는지 돕고, 우리가 작업을 끝났을 때를 알도록 돕고 그리고 클래스의 기능을 개념화하고 그 클래스의 인터페이스를 디자인하는 작업을 돕기 전에, 테스트들을 작성한다는 것을 발견하였습니다. 더 나아가 테스트 선행 개발은 빨리 코드작성 작업을 진행하도록 우리를 고무시킵니다. 그 이유는 우리는 테스트 덕분에 코드의 어떤 부분을 잃어버릴 것에 대해 두려워하지 않게 될 것이기 때문입니다.