[JUnit Test] 2. 통합 테스트

🏗️ 1. 비유로 이해하는 통합 설계 문제

🌰 상황

우리는 콩을 분류하고 투입하는 기계를 만든다. 크기 기준으로 분리한다.

✅ 기존 구조

• 2cm 이하로 분류하는 기계 → 2cm 두유콩 넣는 기계

• 1cm 이하로 분류하는 기계 → 1cm 커피콩 넣는 기계

🚫 문제 상황

• 누군가가 요청했다: “1cm 두유콩 넣는 기계도 만들어줘”

• 그래서 기존 2cm 두유콩 넣는 기계를 개조해서 1cm 두유콩을 처리하도록 수정함

• 그런데 테스트할 때 이렇게 연결하면 터짐

❌ 2cm 이하 분류 기계 → 1cm 두유콩 넣는 기계

✅ 정상적인 설계

1cm 이하 분류 기계
   ├─ 1cm 커피콩 넣는 기계
   └─ 1cm 두유콩 넣는 기계

📌 핵심 이슈

• *상위 분류 기계(2cm)**는 1cm 두유콩 기계를 잘 다룰 수 없음 → 의존성 불일치

• 이런 구조가 누적되면 **전체 설계가 엉망(스파게티 코드)**이 됨

• 이유? 명확한 규칙 없이 기능만 추가한 결과

🧱 2. 그래서 필요한 것이 아키텍처(설계 기법)

• 문제를 해결하기 위해 설계 규칙이 필요하다

• 구조적으로 명확한 계층 분리와 의존 규칙을 지키자

✔️ 개선된 설계 기준 (예: 크기 계층)

💰 3. 비용과 설계 사이의 균형

• 이상적인 설계는 항상 깔끔한 추상화와 분리를 목표로 하지만

• 현실은 예산/시간 제약이 있음

🎯 선택의 기준

🔁 실무 적용 요약

📦 한 줄 요약

"통합 테스트는 설계의 책임과 의존을 검증하는 과정이다. 규칙 없이 연결만 하면 결국 터진다."

✅ 정리 포인트

• 테스트를 잘하려면 좋은 설계가 선행되어야 한다.

• 설계란 결국 의존성 관리이다.

• 추상화와 계층 구조를 도입하고, 테스트할 때도 위에서 아래로 흐름이 맞도록 설계해야 한다.

• 설계에 “절대 정답”은 없고, 돈과 시간에 따라 선택하는 것!