6. Right-BICEP: 무엇을 테스트할 것인가?

• https://github.com/boring-km/JunitPractice

• Right: 결과가 올바른가?

• B: 경계 조건은 맞는가?

• I: 역 관계를 검사할 수 있는가?

• C: 다른 수단을 활용하여 교차 검사할 수 있는가?

• E: 오류 조건을 강제로 일어나게 할 수 있는가?

• P: 성능 조건은 기준에 부합하는가?

6.1 BICEP: 결과가 올바른가?

• 무엇보다도 먼저 기대한 결과를 산출하는지 검증할 수 있어야 한다
• 어떤 작은 부분의 코드에 대해 행복 경로 테스트를 할 수 없다면 그 내용을 완전히 이해하지 못한 것이다.

6.2 B: 경계 조건은 맞는가?

• 코드에 있는 분명한 행복 경로의 경계 조건에 걸리지 않는다면…?

경계 조건들

• 모호하고 일관성 없는 값들 (예: 특수문자 포함된 파일이름)
• 잘못된 양식의 데이터 (예: 이메일 주소 형태가 안 맞는 이메일 주소)
• 수치적 오버플로를 일으키는 계산
• 0, 0.0, “”, null
• 이상적인 기댓값을 훨씬 벗어나는 값
• 중복을 허용해서는 안 되는 목록에 중복 값이 있는 경우
• 정렬이 안 된 정렬 리스트 or 정렬 알고리즘에 이미 정렬된 입력 값
• 시간 순이 맞지 않는 경우 (순서가 정해진 작업을 순서대로 안하는 경우)

6.3 경계 조건에서는 CORRECT를 기억하라

• Conformance(준수): 값이 기대한 양식을 준수하고 있는가?
• Ordering(순서): 값의 집합이 적절하게 정렬되거나 정렬되지 않았나?
• Range(범위): 이상적인 최솟값과 최댓값 안에 있는가?
• Reference(참조): 코드 자체에서 통제할 수 없는 어떤 외부 참조를 포함하고 있는가?
• Existence(존재): 값이 존재하는가(널이 아니거나(non-null), 0이 아니거나(nonzero), 집합에 존재하는가 등)
• Cardinality(기수): 정확히 충분한 값들이 있는가?
• Time(절대적 혹은 상대적 시간): 모든 것이 순서대로 일어나는가? 정확한 시간에? 정시간에?

6.4 I: 역 관계를 검사할 수 있는가?

• NewtonTest.kt 참고

6.5 C: 다른 수단을 활용하여 교차 검사할 수 있는가?

• 코드를 구현하는 가장 좋은 방법을 프로덕션 코드로 사용하고 있다면, 그 코드를 구현하는 조금 다른 방법으로도 같은 결과가 나오는지 확인해보며 교차 검사
• (근데 이렇게까지는 좀처럼 잘 안할듯)

6.6 E: 오류 조건을 강제로 일어나게 할 수 있는가?

• 테스트에서 오류들을 강제로 발생시켜야 한다.
• 고려해볼 시나리오들
  • 메모리가 가득 찰 때
  • 디스크 공간이 가득 찰 때
  • 벽시계 시간에 관한 문제들 (서버와 클라이언트 간 시간이 달라서 발생하는 문제들)
  • 네트워크 가용성 및 오류들
  • 시스템 로드
  • 제한된 색상 팔레트
  • 매우 높거나 낮은 비디오 해상도
• 좋은 단위 테스트는 단지 코드에 존재하는 로직 전체에 대한 커버리지를 달성하는 것에 그치지 않고 끔찍한 결함들에 대한 대비도 해야한다.

6.7 P: 성능 조건은 기준에 부합하는가?

• 추측만으로 성능 문제에 바로 대응하기보다는 단위 테스트를 설계하여 진짜 문제가 어디에 있으며 예상한 변경 사항으로 어떤 차이가 생겼는지 파악해야 한다.
• 어떤 코드가 특정 시간 안에 실행되는지 실행시간을 재서 확인해보는 테스트
• 최대한 프로덕션 환경과 비슷한 환경에서 테스트를 해서 성능 테스트를 진행해본다.
• 실제 데이터로 해야하며 추측을 기반으로 하면 안된다.

6.8 결론

• Right-BICEP 암기법을 활용하여 행복 경로, 경계 조건과 오류 조건을 다루는 테스트를 작성해야 함을 기억하자