정보처리기사 기출 핵심 ㉝ 소프트웨어 테스트 전략과 TDD 완전 정복

소프트웨어 테스트의 중요성

테스트는 소프트웨어 품질 보증의 핵심 활동입니다. 정보처리기사 시험에서는 테스트 피라미드, TDD 방법론, 다양한 테스트 유형(단위·통합·E2E), 계약 테스트, 테스트 더블(모의 객체) 개념이 자주 출제됩니다.

테스트 피라미드(Test Pyramid)

Mike Cohn이 제안한 테스트 전략으로, 비용과 속도를 고려한 최적 테스트 구성을 제시합니다.

• 단위 테스트(Unit Test): 피라미드 하단. 가장 많은 비중. 빠르고 저렴. 개별 함수·메서드·클래스 검증
• 통합 테스트(Integration Test): 중간 계층. 컴포넌트 간 상호작용 검증. DB·API 연동 포함
• E2E 테스트(End-to-End Test): 최상단. 실제 사용자 시나리오 검증. 가장 느리고 비쌈

안티패턴인 “아이스크림 콘”은 E2E 테스트가 많고 단위 테스트가 적은 역전된 구조로 유지보수 비용이 높습니다.

TDD(Test-Driven Development)

Kent Beck이 제안한 개발 방법론으로 “Red → Green → Refactor” 사이클을 반복합니다.

• Red: 실패하는 테스트를 먼저 작성
• Green: 테스트를 통과하는 최소한의 코드 작성
• Refactor: 코드 품질 개선(테스트는 여전히 통과)

장점: 설계 개선, 회귀 방지, 자동화된 문서. 단점: 초기 개발 속도 저하, 학습 곡선

BDD(Behavior-Driven Development)

TDD에서 발전한 방법론으로 비즈니스 관점의 시나리오로 테스트를 작성합니다. Gherkin 언어(Given-When-Then)를 사용합니다.

• Given: 사전 조건
• When: 행동
• Then: 예상 결과

도구: Cucumber(Java), Behave(Python), SpecFlow(.NET)

계약 테스트(Contract Test)

마이크로서비스 간 API 계약을 검증하는 테스트입니다. Consumer Driven Contract Testing이 대표적 접근법입니다.

• Consumer: API를 호출하는 쪽에서 기대하는 계약(Pact)을 정의
• Provider: 계약을 실제 API와 검증(Pact Verification)
• Pact Broker: 계약을 중앙에서 저장·공유하는 서버

테스트 더블(Test Double)

• Mock: 기대 동작을 사전 정의. 호출 여부·횟수 검증. Mockito(Java)
• Stub: 미리 정해진 값 반환. 단순 대체
• Spy: 실제 객체를 감싸서 호출 기록. 부분적 Mocking
• Fake: 실제 동작하는 경량 구현체. In-Memory DB

정보처리기사 기출 핵심 정리

• 테스트 피라미드: 단위(많음) > 통합 > E2E(적음)
• TDD: Red(실패) → Green(통과) → Refactor 사이클
• BDD: Given-When-Then 시나리오 기반
• 계약 테스트: Consumer가 계약 정의, Provider가 검증
• Mock vs Stub: Mock은 동작 검증, Stub은 데이터 반환