(A-SPICE 17회차) SWE.4: 단위 시험은 개발자의 양심입니다!

🧪 17회차: SWE.4 – 단위 시험은 개발자의 양심입니다!

“코드야, 너 제대로 일하는 거 맞니?”
🤖 단위 시험(Unit Test)은 우리가 코드에게 진실을 묻는 시간입니다!

---

🎯 SWE.4란?

SWE.4는 소프트웨어 단위 시험(Unit Verification) 프로세스를 의미합니다.
쉽게 말해, “우리가 짠 코드 단위(함수나 모듈)가 제대로 동작하는지 검증하는 것”이죠!

---

🧠 왜 중요할까요?

• “이거 빌드되니까 되는 거 아님?” → ❌ 큰 착각!
• “시뮬레이터에서 잘 돼요!” → 🚗 실차에서 터지면 어쩌려고요!

단위 시험은…

• 💣 잠재적 버그를 초기에 제거
• 💡 기능별 책임 분리가 잘 되었는지 확인
• 🔍 정적 분석 + MISRA-C 검사로 신뢰도 UP!

---

⚙️ SWE.4에서 해야 할 핵심 활동들

✅ 1. 단위 시험 계획 수립

• 시험 대상 정의 (함수/클래스/모듈)
• 시험 전략 수립 (Black-box, White-box)

✅ 2. 시험 케이스 설계

• 정상/이상 입력 모두 고려
• 경계 조건, 에러 처리도 놓치지 않기!

✅ 3. 시험 수행 & 결과 기록

• 시험 도구를 이용해 자동 시험 (ex. Google Test, Tessy, VectorCAST)
• 시험 결과는 리포트로 보관 📄

---

🔍 정적 분석 vs. 동적 시험?

구분	설명	예시
정적 분석	실행 없이 코드 검토	MISRA-C 규칙 위반 검사, 코드 복잡도 분석
동적 시험	실제 실행을 통한 시험	입력 → 함수 실행 → 출력 확인

🎯 정적 분석은 SWE.4에서 아주 중요한 전제 조건입니다!

---

🚦 정적 분석도 시험이다!

자동차 소프트웨어는 대부분 MISRA-C 기반으로 개발되죠.
SWE.4에서는 다음이 필수입니다:

• 🔍 MISRA-C 룰 체크 (e.g. "goto 쓰지 마!", "전역 변수 남용 금지")
• 🧹 코드 복잡도 측정 (Cyclomatic Complexity < 10 유지 권장)
• 🚨 Code Smell 제거 (Dead Code, Unreachable Code 등)

"코딩은 예술이고, 정적 분석은 미술 선생님이다."

---

🧱 SWE.4의 현실적인 어려움?

• 단위 시험 코드 작성이 귀찮고 오래 걸림
• Legacy 코드에는 테스트 포인트 자체가 없음
• 시험 결과를 형식적으로만 보고함 (← 아주 위험!)

---

🧯 그래서 어떻게 대응할까?

리소스 부족한 회사라면?

• 최소한 중요 모듈부터 시험 (우선순위 기반 전략)
• 정적 분석 자동화 툴 도입 (e.g. Polyspace, QAC, PC-lint)
• 시험 코드 작성은 리뷰 대상 포함! (코드 품질이 생명)

---

💬 현업에서 자주 하는 질문들

❓ “시험 코드도 리뷰해야 하나요?”
✔️ 네, 시험 코드도 결국 제품의 일부입니다.

❓ “정적 분석이 불합격이면 기능은 잘 돼도 NG인가요?”
✔️ 네, 기능이 잘 되어도 코드 규칙 위반이면 불합격 처리될 수 있어요.

❓ “TDD(테스트 주도 개발)는 너무 이상적인 거 아닌가요?”
✔️ 이상적이지만, 핵심 모듈에는 적극 적용할수록 유지보수 효율이 올라갑니다!

---

🧪 SWE.4 요약 정리!

항목	내용
무엇을?	함수, 모듈 단위로 시험
어떻게?	시험 계획 → 시험 케이스 설계 → 시험 수행
도구는?	Tessy, VectorCAST, Google Test 등
핵심은?	정적 분석 + MISRA-C 검사 + 단위 시험 코드 작성

---

🔮 다음 회차 예고: 18회차 – SWE.5, 소프트웨어 통합 시험

이제 단위 시험을 끝냈다면?
모듈들이 잘 어울리는지, 통합 시험으로 확인해야겠죠!

“혼자 잘하던 모듈도, 모이면 싸운다?!”

다음 편에서는 SWE.5 – 소프트웨어 통합 시험의 난이도와 즐거운(?) 현실을 함께 풀어봅니다!