Right-BICEP (무엇을 테스트 할지)

* Right-BICEP

> 무엇을 테스트 할지를 결정하는 방법

> Right (결과가 올바른가?)

- Test 의 목적과 동작을 올바르기 이해하여, 정상적으로 동작했을 때의 결과가 올바른지 판단할 수 있어야 한다
- 어떤 작은 부분의 코드에 대해 행복 경로 테스트를 할 수 없다면 그 내용을 완전히 이해하지 못한 것이다
    (제대로 이해하기 전까지 추가 개발은 잠시 보류하는 것이 좋다)

> B (Boundary Conditions 이 맞는가?)

- 분명한 행복 경로는 입력 값의 양극단을 다루는 코드 시나리오의 경계 조건에 걸리지 않을 수도 있다
- 수많은 결함은 이런 Corner case 이므로 이것들을 테스트 해야한다

: 모호하고 일관성 없는 입력 값
    (e.g. 특수문자가 포함된 파일 이름)

: 잘못된 양식의 데이터
    (e.g. domain 이 빠진 이메일 주소)

: 수치적 오버플로를 일으키는 계산

: 비거나 빠진 값
    (0, "", null)

: 이성적인 기댓값을 훨씬 벗어나는 값
    (e.g. 150세의 나이)

: 중복을 허용해서는 안되는 목록에 중복 값이 있는 경우

: 정렬이 안 된 정렬 리스트 혹은 그 반대
: 시간 순이 맞지 않는 경우

- CORRECT (잠재적인 경계 조건)

: 위와 같은 경계 조건들을 쉽게 기억하기 위한 방법

> I (Inverse Relationship 을 검사할 수 있는가?)

- 때때로는 논리적인 역 관계를 적용하여 행동을 검사할 수 있다
    (e.g. 제곱근과 제곱의 관계)

> C (Cross-check 할 수 있는가?)

- 문제 해결을 위한 무수한 해법 중에 최적의 해법을 선택했을 때, 나머지(패배자) 해법들을 교차 검사에 활용할 수 있다
    (시간이 너무 느리거나 유연하지 않아도 믿을 수 있고 참값을 보장한다면)

> E (Error Conditions 를 강제로 일어나게 할 수 있는가?)

- 모든 실전 문제를 해결하기 위해서는 테스트도 오류들을 강제로 발생시켜야 한다

: 메모리가 가득 찰 때
: 디스크 공간이 가득 찰 때
: 벽시계 시간에 관한 문제들
    (즉, 서버와 클라이언트 시간이 달라서 발생하는 문제들)
: 네트워크 가용성 및 오류들
: 시스템 부하
: 제한된 색상 팔레트
: 매우 높거나 낮은 비디오 해상도

> P (Performance Characteristics 기준에 부합하는가?)

- 추측만으로 성능 문제에 바로 대응하기보다는 단위 테스트를 설계하여 진짜 묹가 어디에 있으며 예상한 변경 사항으로 어떤 차이가 생겼는지
    파악해야 한다