통합테스트와 단위테스트 그리고 TDD
이번 3주차 발자국을 작성하기에 앞서서, 저는 다른 스터디원분들이 작성해준 테스트 시 사용되는 애노테이션의 사용법과 각 차이점 보다는 통합 테스트와 단위테스트 그리고 TDD를 수행해야하는 근본적인 이유에 대해서 작성하였으며 이를 통해 얻고자 하는 것은 궁극적으로 무엇인가에 대해서 작성하였습니다.
통합 테스트란??
메서드가 어떠한 상황에서 어떻게 작동해야된다.라는 것을 보장하는 것이 단위테스트라면 통합테스트는 A객체와 B.객체가 만나서 협력 시 어떻게 동작한다라는 것을 보장하기 위해서 수행하는 것이다.
통합 테스트는 왜 해야하는가?
“불안감”때문이다. 정확히 말하면 시스템 전체가 의도한 대로 작동하는지 확인하고 신뢰할 수 있는 상태로 배포하기 위해서이다. 통합 테스트를 해야하는 근본적인 이유는 아래와 같다.
“기능은 우리의 의도대로 작동하지 않을 수 있다.”
각각의 모듈은 단위테스트를 통해서 잘 돌아가는 것을 보장받았지만 여러 모듈이 협력해 하나의 트랜잭션을 완벽히 수행해야할 때 우리의 생각과는 다르게 동작할 수 있다.
실제 연결되면 의존 관계, 데이터 흐름, 부작용등으로 인해 예상 밖의 오류가 발생할 수 있다.
“배포시 문제를 일으킬 수 있는 불안감”
단위 테스트는 개별 단위만 보장할 뿐 전체 흐름은 검증하지 않는다.
실사용자 시나리오에서 시스템이 어떻게 반응하는지 확인해야만 안정적으로 배포가 가능하다.
통합 테스트는 바로 실제 사용 시나리오를 기반으로 한다.
통합 테스트의 본질적인 목적
전체 시스템이 유기적으로 동작하는지에 대한 신뢰성을 검증하는 것
API, DB, 외부 서비스등 데이터 흐름을 확인하며 모듈간 상호작용 확인
단위 테스트로 잡지 못하는 복합적인 문제 사전 탐지 및 버그 사전 발견
배포 안정성 확보
단위 테스트란?
하나의 함수, 메서드, 클래스와 같은 가장 작은 코드 조각이 예상한 대로 작동하는지 검증하는 테스트이다.
가장 좁은 범위의 테스트
일반적으로 입력 → 기대 결과 비교
외부 시스템에 의존하지 않고 격리된 환경에서 수행되어야 한다. 외부 시스템을 의존할 경우 Mock으로 대체
단위 테스트는 왜 해야하는가?
로직 오류, 오타, 예외처리 누락 등 언제든지 발생 가능한 작은 범위의 버그를 잡아내기 위해서 수행한다.
코드가 많아지고 길어질수록 발생하는 “다른 곳의 영향은 없나” 하는 공포가 커지게 되고, 이는 팀 전체에 끼치게ㅔ 된다.
시간이 흐른뒤에 코드를 보게 되면 믿음이 흐릿해지고 제대로 작동하는지에 대한 의구심이 들게 된다.
위와 같은 사유로 단위테스트는 작성되어 팀 전체의 심리적 불안 요소를 제거하거하고, 코드를 “검증된 사실” 및 “프로젝트를 설명하는 문서”와 같은 존재가 되어야 한다.
단위 테스트는 “이 코드가 나의 의도대로 동작한다” 라는 것을 기계적으로, 반복 가능하게 자동으로 입증하는 절차이며 리팩토링 시 언제든지 업데이트가 가능한 살아있는 문서가 된다.
TDD란?
“테스트 코드를 먼저 작성(문서를 먼저 작성)하고, 해당 테스트를 통과시키기 위한 실제 코드를 작성하는” 개발 방식이다.
TDD는 3단계의 사이클이 존재하는데 Red, Green, Refactor단계로 나뉘게 된다.
Red: 먼저 해당 기능에 맞는 시나리오 테스트를 작성한다.(실제 프로덕션 코드가 없기 때문에 실패한다.)
“정확히 어떤 동작을 수행해야 하나?”를 먼저 고민하게 만듦으로써 설계 사고를 유도한다.
Green: Red 테스트 코드가 성공할 수 있도록 실제 프로덕션 코드를 작성한다.
해당 단계에서는 Red에서 실패한 테스트 코드가 성공만 하면 되기 때문에 최대한 빠르게 작성한다.
사고의 깊이를 줄이고, 가장 단순한 형태의 로직만 나열하여 성공하도록 만든다.
완벽하게 작성하는 것이 아닌 작동이 가능한 코드를 만드는 것이 원칙이다.
Refactor: Green에서 휘갈겨 작성한 코드를 Refactoring하는데 있어서 Red에서 작성한 테스트 코드는 건들지 않는다.
중복을 제거하고, 가독성을 향상시키는데 초점을 둚으로써 코드 품질을 개선한다.
테스트가 통과되었기 때문에 리팩토링 과정에서 테스트가 실패할 경우 빠른 피드백을 얻을 수 있다.
댓글을 작성해보세요.
