실용주의 단위 테스트. 7장. 경계 조건: CORRECT 기억법.

경계 조건에 관계된 결함들을 미연에 방지하기 위해서 작성해야하는 테스트들을 살펴봅니다.

 

Conformance: 값이 기대한 양식을 준수하고 있는가?

데이터가 기대하고 있는 형식을 갖추고 있는지 테스트해야 합니다. 이메일 주소나 전화번호 같은 문자열 데이터는 양식을 검증하는 테스트를 작성할 필요가 있습니다. 좀 더 복잡한 구조적 데이터의 경우에는 경계 조건을 조합하면 테스트 수가 더욱 늘어납니다. 헤더, 데이터, 트레일러로 구성된 데이터를 가정했을 때, 다음과 같은 경계 조건들을 테스트해야 합니다.

- 헤더가 없습니다. 데이터와 트레일러만 존재합니다.
- 데이터가 없습니다. 헤더와 트레일러만 존재합니다.
- 트레일러가 없습니다. 헤더와 데이터만 존재합니다.
- 트레일러만 있습니다.
- 헤더만 있습니다.
- 데이터만 있습니다.

 

Ordering: 값의 집합이 적절하게 정렬되거나 정렬되지 않았나?

순서가 있는 데이터를 다룰 경우, 정렬이 필요한지 혹은 기대한 대로 정렬이 되고 있는지 확인하는 테스트를 작성해야 합니다.

* 정렬 상태가 경계 조건인지는 약간 의문이지만, 실수하기 쉬운 부분인 것은 분명한 것 같습니다.

 

Range: 이성적인 최솟값과 최댓값 안에 있는가?

비즈니스 로직 상에서 음수가 될 수 없는 값이지만 이를 int로 정의함으로써 코드 레벨에서는 아무 제약이 없는 상황이 종종 일어납니다. 코드 레벨에서도 이를 제약하기 위해 int를 클래스로 추상화한다거나 하는 방법을 사용할 수 있습니다. 만약 이 같은 제약을 테스트로 검증하고자 한다면, 사용자 정의 햄크레스트 매처를 @After 메서드에서 사용하여 모든 테스트가 제약을 따르고 있는지 확인할 수 있습니다.

 

Reference: 코드 자체에서 통제할 수 없는 어떤 외부 참조를 포함하고 있는가?

테스트 수행에 필수적인 사전 조건이 존재하는지, 혹은 통제할 수 없는 외부 의존성이 존재하는지를 확인해야합니다. 통제가 불가능한 의부 의존성은 의존성 주입 등의 방법을 이용해 테스트에서 제거해나가야 합니다.

 

Existence: 값이 존재하는가?

우리는 프로그래머로서 보통 행복 경로를 만드는 데 무엇보다 주력합니다. 하지만 불행 경로에 대한 테스트를 잊어선 안됩니다. null check가 가장 일반적인 상황이겠지만, 그 외에도 파일이 없다거나 네트워크가 다운되었을 때의 동작을 확인하는 테스트를 작성할 필요가 있습니다.

 

Cardinality: 정확히 충분한 값들이 있는가?

'길이 12미터의 울타리를 세우려할 때 3미터마다 울타리 기둥을 세워야한다면, 울타리 기둥은 몇 개나 필요할까요?' 한 끗 차이로 발생할 수 있는 오류들을 방지하기 위해 테스트를 어떻게 작성하면 좋을지 고민해야 합니다. 0-1-n의 법칙에 따라 테스트를 추가합니다. 수시로 갱신되는 10개의 목록에 대해 생각해볼만한 테스트 목록은 다음과 같습니다.

- 목록에 항목이 하나도 없을 때 목록 출력하기
- 목록에 항목이 한 개만 있을 때 목록 출력하기
- 목록에 항목이 없을 때 한 항목 추가하기
- 목록에 항목이 하나만 있을 때 한 항목 추가하기
- 목록에 항목이 아직 열 개 미만일 때 한 항목 추가하기
- 목록에 항목이 이미 열 개가 있을 때 한 항목 추가하기

 

Time: 모든 것이 순서대로 일어나는가? 정확한 시간에? 정시에?

시간에 관하여 고려해야할 측면은 몇 개는 다음과 같습니다.

- 상대적 시간(시간 순서): 기능의 수행 순서는 맞는지, 너무 오래 걸리지는 않는지.
- 절대적 시간(측정된 시간): 지역의 시간대에 따라 동작이 달라지지는 않는지.
- 동시성 문제들