TDD(Test Driven Development)
내가 개발할 때는 요구사항 수집 후 개발한 후 테스트를 하게 됐다.
배포를 하고 계속해서 수정사항이 바뀌었는데 TDD를 통해서 이런 점을 보완한다고 한다.
근데 TDD가 뭔지를 모른다. 알아보자.
내가 이해한 바로는 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여
구현하는 것이다.
테스트 → 정보처리기사할 때 테스트 종류가 많았는데 무엇이 있는지 한 번 보자
테스트의 종류
● 단위 테스트 : 매우 낮은 수준으로 애플리케이션의 소스와 가깝다. 소프트웨어에서 사용하는 클래스
구성 요소 또는 모듈의 개별 메서드와 함수를 테스트하는 것으로 구성되어 있다.
단위 테스트는 일반적으로 자동화 비용이 상당히 저렴하며 지속적 통합 서버에서 매우
빠르게 실행할 수 있다.
● 통합 테스트 : 애플리케이션에서 사용되는 여러 모듈 또는 서비스가 잘 작동하는지 확인한다.
예를 들어, 데이터 베이스와의 상호 작용을 테스트하거나 마이크로 서비스가 예상대로
함께 작동하는지 확인하는 것일 수 있다.
● 기능 테스트 : 기능 테스트는 애플리케이션의 비즈니스 요구 사항에 초점을 맞춘다. 작업의 출력만 확인하여
작업을 수행할 때 시스템의 중간 상태는 확인하지 않는다.
● 엔드투엔드 테스트 : 전체 환경에서 사용자의 행동을 복제해서 테스트하는 것이다.
● 수용 테스트 : 시스템이 비즈니스 요구 사항을 충족하는지 확인하는 공식적인 테스트
● 성능 테스트 : 요청을 실행할 때의 응답 시간을 관찰하거나 시스템이 대량의 데이터에 대해 어떻게 동작하는지
확인할 수 있다.
● 스모크 테스트 : 시스템의 주요 기능이 예상대로 작동하고 있다는 확신을 주는 것이다.
1) Red 단계에서는 실패하는 테스트 코드를 작성한다.
2) Green 단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.
3) Blue 단계에서는 중복 코드 제거, 일반화 등의 리팩토링을 수행한다.
실패하는 테스트 코드를 작성할 대까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할
정도의 최소 실제 코드를 작성하는 것이다.
기존에는 개발하고 에러가 나면 고치느라고 결국 모든 소스를 다시 봐야하는 상황이 있었는데 확실히 효과적일 것 같다.