Chapter 02. 명세 기반 테스트

• 명세 기반 테스트란 애자일의 유저 스토리나 UML의 유스 케이스 같은 프로그램 요구사항을 테스트의 입력으로 사용
• 요구사항은 무엇을 수행하고, 무엇을 수행하면 안되는지 명확하기 때문에 테스트 적용시 가장 우선적으로 적용
• 요구사항에 따라 개발 진행 후엔 버그를 잡기 위한 "테스트 모드"로 몰입하자
  • 달성하고자하는 일련의 로직 절차를 구현하는 중에 생각나는 테스트 케이스는 일단 체크 리스트에 넣어두고, 나중에 "테스트 모드" 때 버그를 잡자
• 완벽한 테스트는 거의 불가능. 실용적으로 접근하자

2.1 요구사항이 모든 것을 말한다

2.1.1 1단계: 요구사항과 입출력에 대해 이해하기

• 요구사항은 어떻게 작성했든 세부분으로 이루어짐
  1. 비즈니스 규칙. 즉 함수가 무엇을 수행해야하는지
  2. 입력. 무엇을 입력해야하는지
  3. 출력. 입력에 의해 무엇이 출력이되어야하는지
• 위 부분들을 생각하는 과정은 함수가 어떻게 동작해야할지 생각할 때 유용

2.1.2 2단계: 여러 입력값에 대해 프로그램이 수행하는 바를 탐색하기

• 느낌가는대로 여러 입력값으로 테스트 케이스 작성
• 이 테스트 케이스들을 통해 코드를 더 잘 알게 됐다면 Good!
• 필자의 경우 머릿속에 프로그램이 어떻게 동작할지 명확한 그림을 가지게 돼면 탐색 단계 중단
• 코너 케이스를 도출해내는 것보다 프로그램을 더 잘 이해한다는 것에 초점

2.1.3 3단계: 테스트 가능한 입출력과 구획을 탐색하기

• 입력값을 달리해도 출력값이 같은 동등한 테스트는 한번만 하자.
• 입력값을 달리하면서 케이스를 작성하다보면 어떤 구획(부류)가 생긴다.
  • 이런 구획을 심도있게 탐색하다보면 이전에 보지못한 입력케이스를 찾을 수 있음

2.1.4 4단계: 경계 분석하기

• 시스템의 버그는 경계에서 가장 많이 발생
• 경계를 찾으면 경계 근처를 옮겨가며 어떤 일이 발생하는지 테스트

5단계, 6단계

• 생략