테스트 코드 개념

✅ 목차

1. 테스트를 왜 해야할까?
2. 테스트 코드는 왜 필요할까?
3. 테스트 코드 작성의 원칙
4. 테스트의 종류
5. 테스트 코드는 어떻게 작성해야할까?

---

1. 테스트를 왜 해야할까?

 

• 기능이 요구사항대로 잘 동작하는지 확인하기 위함
• 완벽한 코드를 한 번에 작성하기 어렵고 예상치 못한 입력으로 장애가 발생할 수 있기 때문에 다양한 케이스를 테스트로 검증해야 한다.

 

테스트 방법

1. Swagger, Postman 등으로 다양한 케이스를 직접 확인
2. QA 과정에서 UI, 프론트, 서버를 아우르는 테스트
3. 테스트 코드를 작성해 자동화된 검증 수행

 

---

2. 테스트 코드는 왜 필요할까?

 

• 버그를 조기에 발견
  • 개발 단계에서 버그를 미리 찾아 수정 가능
• 코드 품질 개선
  • 테스트 작성이 어려운 코드를 개선하게 되고, 클래스 역할과 책임을 명확히 하여 클린 코드 작성에 도움
• 배포 안정성 보장
  • CI/CD 환경에서 테스트 없이 자동 배포 시 기능 문제 발견 어려움
• 리팩토링 용이
  • 테스트 코드가 있으면 리팩토링 후에도 기존 기능 정상 동작 보장 가능
• 시간 절약 및 사이드이펙트 방지
  • 서비스 성장 시 수많은 기능 검증에 도움, 기존 기능 회귀 테스트 가능

 

---

3. 테스트 코드 작성의 원칙

FIRST 원칙

• F (Fast): 빠르게 실행되어야 한다
• I (Isolated): 테스트는 독립적이어야 하며 외부 시스템에 의존하면 안 된다
• R (Repeatable): 반복 실행해도 항상 같은 결과여야 한다
• S (Self-validating): 테스트는 스스로 검증 가능해야 하며, 개발자의 수동 확인 필요 없어야 한다
• T (Timely): 테스트 코드는 즉시 작성해야 한다

 

테스팅 7원칙

 

1. 결함 존재의 원칙
   • 테스트는 결함이 존재함을 보여주지만, 결함이 없음을 증명하지는 못한다.
2. 완전한 테스트 불가능의 원칙
   • 모든 경우를 다 테스트하는 것은 불가능하므로 우선순위를 정해 테스트해야 한다.
3. 조기 테스트의 원칙
   • 테스트는 가능한 빨리, 개발 초기부터 시작해야 한다.
4. 결함 집약의 원칙
   • 전체 결함의 대부분이 특정 부분에 집중되어 발생한다.
5. 피드백의 원칙 (Pesticide paradox)
   • 같은 테스트만 반복하면 새로운 결함을 찾기 어렵다. 테스트를 주기적으로 갱신해야 한다.
6. 테스트는 상황 의존적임
   • 프로젝트나 환경에 따라 적절한 테스트 전략이 달라진다.
7. 결함 없는 소프트웨어와 테스트 없음의 원칙
   • 결함이 없다고 해서 요구사항을 충족하는 것은 아니다. 요구사항 기반 테스트가 필요하다.

 

---

4. 테스트의 종류

단위 테스트 (Unit Test)

• 함수, 메서드, 클래스 단위의 최소 범위 테스트
• 빠르고 에러 위치 파악 용이
• 실제 환경과 다를 수 있어 통합 이슈는 발견 어려움

 

통합 테스트 (Integration Test)

• 여러 모듈 결합 상태 테스트, DB, 외부 API 포함 가능
• 연동 문제 조기 발견 가능
• 실행 속도 느리고 문제 원인 파악 어려울 수 있음

 

테스트 피라미드

• 위로 갈수록 테스트 비용이 비싸지고 속도는 감소된다

---

5. 테스트 코드는 어떻게 작성해야할까?

 

• 다양한 상황 고려한 케이스 작성
  • 정상 케이스, 경계 조건(엣지 케이스), 예외 상황 포함
• 각 테스트는 독립적이어야 한다
  • 테스트 간 의존성 금지, DB 테스트 시 롤백 필수
• 의미 없는 테스트 지양
  • 핵심 가치와 중요 기능부터 우선 테스트
  • 단순 커버리지 증가에만 집중하지 않기

---

마무리

 

• 테스트 코드는 만능이 아니며, 다양한 케이스와 충분한 양이 장애를 완전히 막지는 못한다.
• 버그 발생 시 테스트 케이스를 추가해 재발 방지 및 코드 품질 개선 도구로 활용해야 한다.