TIL - 37 : TDD - Basic
in Study Log on Today I learned
TDD - Test Driven Development
- 소프트웨어 테스트, 제품이나 서비스의 품질을 확인
- 제품이 예상하는 대로 동작하는지 확인 (함수나, 특정한 기능, UI, 성능 등)
- 자동화, 속도, 쉽게작성, 높은 커버리지
- 테스트를 하는 이유? 장점?
- 기능이 정상적으로 동작하는지
- 요구 사항 만족
- 이슈에 대해 예측
- 버그를 빠르게 발견
- 손쉬운 유지 보수
- 코드의 품질 향상
- 코드간 의존성을 낮춤
- 좋은 문서화
- 시간을 절약
사용자 입장에서 코드를 작성
모든 요구 사항(목표)에 대해 점검
시스템 전반적인 설계 향상
개발 집중력 향상
- Test Pyramid (위로 올라갈수록 비용 발생, 속도는 느림)
- E2E Test (end-to-end)
- 통합(integration) 테스트 (모듈들, 클래스들)
- 단위(unit) 테스트 (함수, 모듈, 클래스)
작은단위의 코드만 테스트 코드로 작성
사용자 입장에서 코드를 작성
테스트 작성 -> 테스트 실패 -> 성공할 정도로 작게 다시 작성
코드를 배포하기 전에, 코드를 PR 하기전에, Merge 전에 Test코드와 같이
Repo에 올려야 함 - 테스트 코드 문서화- CI - Continuous Integration (지속적인 통합)
- 통합을 위한 단계(빌드, 테스트, 머지)의 자동화
- CD - Continuous Deployment (지속적인 배포)
테스트코드 중요한 점
한번 작성된 테스트 코드는 영원히 유지보수 해야 한다.
- 내부 구현 사항을 테스트 하면 안된다.
- 내부에서 변수가 변경된다던가 코드가 조금이라도 변경되면 테스트코드가 실패
재사용성 높이기 (테스트 유틸리티)
배포용 코드와 철저히 분리하기
- 테스트 코드를 통한 문서화
좋은 테스트의 원칙
- 느린것에 대한 의존성 낮추기
- 파일, 데이터 베이스, 네트워크 -> stub 이나 mock 사용
최소한의 유닛으로 검증하기 - 독립적이고 집중적으로 유지
실행할 때마다 동일한 결과를 유지
스스로 결과를 검증하기
- 사용자에게 배포되기 이전에 테스트 코드 작성
테스트의 범위
- 모든 코너 케이스에 대해 테스트를 하기
- 잘못된 포맷의 인풋, null, 특수문자, 잘못된 이메일, 작은 숫자 등
역관계를 적용해서 결과값을 확인
- 다른 수단을 이용해서 결과값이 맞는지 확인
