테스트하기 어려운 코드의 특징과 이것이 설계와 관련된 문제에 미치는 영향
특징 | 테스트 문제 |
설계 문제 |
전역변수를 사용한다 |
테스트할 때마다 모든 전역 변수를 초기화해야 한다. 그렇지 않으면 테스트가 서로의 결과에 영향을 줄 수 있다. |
어느 함수가 어떤 부수적인 효과를 가지는지 판별하기 어렵다. 각각의 함수를 별도로 고려할 수 없다. 모든 게 제대로 작동하는지 알려면 프로그램 전체를 생각해야 한다. |
코드가 많은 외부 컴포넌트를 사용한다 |
처음에 설정할 일이 너무 많아서 테스트를 작성하기 힘들다. 따라서 테스트를 작성하는 일이 즐겁지 않아 테스트 작성을 회피한다. |
이러한 외부 시스템 중에서 어느 하나가 제대로 작동하지 않으면 프로그램이 실패한다. 프로그램에 가한 수정이 어떤 효과를 낳을지 알기 어렵다. 클래스들을 리팩토링하기 어렵다. 시스템이 더 많은 실패 모드와 복구 경로를 가지게 된다. |
코드가 비결정적인(nondeterministic) 행동을 가진다 |
테스트가 변덕스럽고 안정적이지 못하다. 가끔 실패하는 테스트가 그냥 무시된다. | 프로그램이 경합 조건이나 재생하기 어려운 버그를 가지고 있을 확률이 높다. 프로그램의 논리를 따라가기가 어렵다. 현장에서 발생한 버그를 추적해서 수정하기가 매우 어렵다. |
테스트하기 좋은 코드의 특징
특징 |
테스트 장점 |
설계 장점 |
클래스들이 내부 상태를 거의 가지고 있지 않다 |
메소드를 테스트하기 전에 설정할 일이 거의 없고 감추어져 있는 상태가 별로 없기 때문에 테스트 작성이 수월하다. |
소수의 내부 상태를 가지는 클래스는 이해하기 더 간단하고 쉽다. |
클래스/함수가 한 번에 하나의 일만 수행한다 | 더 적은 테스트 코드가 요구된다. |
더 작고 간단한 컴포넌트는 더 잘 모듈화되어있고, 시스템이 서로 더 멀리 떨어져 있다 |
클래스가 다른 클래스에 의존하지 않고, 서로 상당히 떨어져 있다 |
각 클래스가 독립적으로 테스트된다 (여러 클래스를 동시에 테스트할 때에 비해서 훨씬 쉽다) |
시스템이 병렬적으로 개발될 수 있다. 클래스가 쉽게 수정될 수 있고, 혹은 시스템의 나머지 부분에 영향을 주지 않으면서 제거될 수도 있다. |
함수들이 간단하고 잘 정의된 인터페이스를 가지고 있다 |
테스트 대상이 잘 정의되어 있다. 간단한 인터페이스는 테스트를 위해서 더 적은 일을 요구한다. |
프로그래머가 인터페이스를 쉽게 배울 수 있어 해당 인터페이스는 재사용될 가능성이 더 높다. |
'Archive' 카테고리의 다른 글
MapReduce (0) | 2012.06.23 |
---|---|
지나친 테스트 (0) | 2012.06.16 |
자기 주변에 있는 라이브러리에 친숙해져라 (0) | 2012.06.16 |
변수의 범위를 좁혀라 (0) | 2012.06.15 |
쇼트 서킷 논리 (Short-Circuit Logic) 오용 말기 (0) | 2012.06.15 |