SqueakByExample:7.3
Jump to navigation
Jump to search
좋은테스트를 만들려면 어떻게 해야할까요?
좋은 테스트 작성은 연습으로 가장 쉽게 학습될 수 있는 기술입니다. 최대의 이익을 얻게 해줄 테스트의 속성을 함께 살펴봅시다.
- 테스트는 반드시 반복실행이 가능해야 합니다. 테스트는 원하는 만큼 반복이 가능해야 하며 항상 동일한 답을 얻을 수 있어야만 합니다.
- 테스트는 사람의 개입 없이 실행되어야만 합니다. 밤에도 테스트를 실행할 수 있어야만 합니다[1].
- 테스트는 기능에 이어질 수 있는 내용[2]이어야 합니다. 그리고 각 테스트의 코드는 할당된 테스트를 모두 담당할 수 있어야 합니다. 테스트는 시나리오로서 작동해야 하며, 당신 또는 다른 사람이 해당되는 테스트의 기능을 파악하기위해 테스트코드를 읽을 수 있는 상태가 되어야 합니다.
- 테스트는 반드시 테스트들이 대상으로 하는 기능보다는 적은 회수로 수정되어야 합니다: 당신의 어플리케이션을 수정할 때마다 관련된 모든 테스트를 바꾸는것은 번거로운일이죠. 이렇게 적은 회수로 테스트를 수정하기 위한 한가지 방법은 테스트를 만들때 테스트할 클래스의 공용 인터페이스에 기반을 두고 만드는겁니다. 만약 테스트가 필요할 만큼 메소드가 충분히 복잡하다고 느껴지는 경우, 개별적 "helper"를 위한 테스트를 작성하는 것은 괜찮지만, 좀더 나은 실행법을 생각해 내었을 때, 그러한 테스트들은 바뀌거나 완전히 버려질 수도 있다는 것을 반드시 생각해 두어야 할것입니다.
위의 (3) 번 항목을 참고로 해서 테스트의 목적을 좁혀, 테스트해야 할 기능과 테스트의 수가 비례하도록 합니다: 시스템의 일부를 변경해도 모든 테스트가 이상이 생기는게 아니라 일부의 테스트만 실패하도록 되어야 합니다. 이런진행방법은 상당히 중요합니다. 왜냐하면 100 개의 테스트 실패는 10개의 테스트 실패보다 심각한 내용이기 때문입니다. 그렇지만, 전체테스트에 모두 실패하는 상황이 불가능한것만은 아닙니다: 특별히, 무언가를 변경한뒤 오브젝트의 초기화나 테스트의 설정에 문제가 생기는경우, 관련된 모든 테스트는 제대로 작동하지 않습니다.
eXtream 프로그래밍에서는 코드를 작성하기 전에 테스트를 먼저 작성할 것을 주장하고 있습니다. 이런주장은 소프트웨어 개발자로서의 깊은 본능과 맞지 않을수도 있습니다. 프로그래머들은 대부분 이렇게 말할겁니다: 계속하고 시도해! 우리는, 코드가 무엇을 코딩하기 원하는지 돕고, 작업을 끝났을 때를 알도록 돕고 그리고 클래스의 기능을 개념화하고 그 클래스의 인터페이스를 디자인하는 작업을 돕기 전에, 테스트를 먼저 작성해야 한다는 것을 발견하게 되었습니다. 더 나아가 테스트를 먼저 만드는 개발방법은 코드를 만드는 작업이 빨리 진행되도록 독려합니다. 왜냐하면 테스트로 인해 중요한걸[3] 잊어버리는것에 대해 두려워하지 않아도 되기때문입니다.