TDD(Test Driven Development)

TDD

Test Driven Development의 약자로 테스트가 주도하는 개발이라는 의미로 해석합니다.

 

1. 항상 실패하는 테스트를 먼저 작성하고 (RED)
2. 테스트를 통과하는 프로덕트 코드를 작성하고 (Green)
3. 테스트가 통과하면 프로덕트 코드를 리팩토링합니다. (Refactor)

 

상세 설명

1. Ask(질문): 테스트 작성으르 통해 시스템에 질문 (결과는 실패로 응답하게 합니다.)
2. Respond(응답): 테스트를 통과하는 코드를 작성해서 질문에 대답 (성공으로 응답하게 합니다.)
3. Refine(정제): 아이디어를 통합하고 불필요한 것은 제거하고, 모호한 것은 명확히 해서 대답을 정제 (리팩토링)
4. Repeat(반복): 다음 질문을 통해 대화를 계속 진행

 

TDD 방법으로는 보통 Unit Test(단위 테스트)와 Integration Test(통합 테스트)를 사용합니다.

 

Unit Test (단위 테스트)

단위 테스트는 응용 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트입니다.

단위 테스트에서 테스트 대상 단위의 크기는 엄격하게 정해져 있지 않지만, 일반적으로 클래스 또는 메소드 수준으로 실행합니다.

단위의 크기가 작을수록 단위의 복잡성이 낮아지기 때문에, 단위 테스트를 활용하여 동작을 표현하기 더 쉬워집니다.

즉, 테스트 대상 단위의 크기를 작게 설정해서 단위 테스트를 최대한 간단하고 디버깅하기 쉽게 작성하면 좋습니다.

소프트웨어를 개발할 때, 소프트웨어 내부 구조나 구현 방법을 고려하여 개발자 관점에서 테스트를 합니다.

그러므로 단위 테스트는 소프트웨어 내부 코드에 관련한 지식을 반드시 알고 있어야 하는 화이트박스 테스트입니다.

 

Integration Test(통합 테스트)

통합 테스트는 단위 테스트보다 더 큰 동작을 달성하기 위해 여러 모듈들을 모아 이들이 의도대로 협력하는지 확인하는 테스트입니다.

모듈을 통합하는 단계에서 수행하는 테스트로, Unit Test를 통해 각 모듈들이 잘 작동되는 것을 확인했다면 이제 이 각 모듈들을 연동해서 테스트를 수행합니다.

통합 테스트는 단위 테스트와 달리 개발자가 변경할 수 없는 부분(ex. 외부 라이브러리)까지 묶어 검증할 때도 사용합니다.

이는 DB에 접근하거나 전체 코드와 다양한 환경이 제대로 작동하는지 확인하는데 필요한 모든 작업을 수행할 수 있습니다.

그러나, 통합 테스트가 응용 프로그램이 완전하게 작동하는 걸 무조건 증명하지는 않습니다.

통합 테스트의 장점은 단위 테스트에서 발견하기 어려운 버그를 찾을 수 있다는 점입니다.

예를 들자면, 통합 테스트에서는 환경 버그(ex. 싱글 코어 CPU에서는 잘 실행되나 쿼드 코어 CPU에서는 잘 실행되지 않음)이 발생할 수 있습니다.

하지만, 단점으로는 단위 테스트보다 더 많은 코드를 테스트하기 때문에 신뢰성이 떨어질 수 있다는 점입니다.

또, 에러가 어디서 발생했는지 확인하기 쉽지 않기에 유지 보수하기 힘들다는 단점도 있습니다.

 

 

참고

https://tecoble.techcourse.co.kr/post/2021-05-25-unit-test-vs-integration-test-vs-acceptance-test/