SAP 단위 테스트: 내 코드는 내가 지킨다! (feat. 자동차 엔진 테스트)

안녕하세요. Rabbit입니다! 🐰

지난 ‘Fit/Gap 분석’ 편에서는 우리 회사만을 위한 맞춤 SAP 설계도를 그리는 법을 알아봤죠?

그 멋진 설계도를 손에 쥔 개발자와 컨설턴트들이 각자의 방에서 열심히 ‘부품’을 만들고 있습니다.

영업팀을 위한 반짝이는 새 주문 프로그램, 구매팀의 업무를 덜어줄 자동 입고 기능, 회계팀이 사랑할 특별 리포트까지! 생각만 해도 든든한 부품들이 하나둘씩 모습을 드러내고 있죠.

그런데 말입니다. 이 모든 부품을 합쳐 ‘SAP’라는 거대한 자동차를 만들기 전에, 문득 이런 생각이 들지 않나요?

“잠깐, 이 엔진… 차에 싣기 전에 제대로 돌아가는 거 맞아?”

네, 맞습니다! 자동차의 심장인 엔진을 차체에 올리기 전에, 엔진 자체에 결함이 없는지 먼저 테스트하는 건 너무나 당연한 순서겠죠.

오늘 SAP 테스트 5부작 3편에서는 바로 이 과정, 개발자가 자신의 작업물을 스스로 검증하는 첫 번째 관문인 SAP 단위 테스트(Unit Test)에 대해 쉽고 재미있게 파헤쳐 보겠습니다.

SAP 단위 테스트란? 내 차의 심장, 엔진부터 테스트!

SAP 단위 테스트(Unit Test)는 이름 그대로에요.

시스템을 이루는 가장 작은 단위(Unit)가 혼자서도 잘 작동하는지 테스트하는 활동이죠. 여기서 ‘단위’는 프로그램 하나, 함수 하나 같은 아주 작은 조각을 의미합니다.

여전히 감이 잘 안 오신다구요? 우리가 만들려는 SAP 시스템을 ‘최첨단 자동차 한 대’라고 상상해봅시다.

단위 테스트는 이 자동차를 조립하기 전에, ‘엔진’ 부품만 딱 떼어서 테스트 장비에 연결해보는 거예요. 시동은 잘 걸리는지, 이상한 소음이나 진동은 없는지, 설계한 만큼의 힘(출력)은 제대로 나오는지!

오직 ‘엔진’의 성능과 품질만을 독립적으로 검증하는 과정이죠. 이때 핸들이나 브레이크, 타이어는 전혀 신경 쓰지 않아요. 지금은 오직 엔진의 완벽함이 중요하니까요.

그럼 이 중요한 테스트는 누가 할까요? 바로 그 엔진을 만든 사람!

즉, 해당 프로그램을 코딩한 개발자나 기능을 설정한 모듈 컨설턴트가 직접 수행합니다. 다른 사람에게 “이거 좀 봐주세요” 하고 넘기기 전에, “내 작품은 내가 책임진다!”라는 장인 정신으로 품질을 스스로 보증하는 첫 번째 단계인 셈이죠.

‘큰 문제를 미리 막으려면, 작은 단계부터 완벽해야 한다’는 것, 이것이 바로 단위 테스트의 핵심 철학입니다. 최고급 벽돌(Unit)이 모여야 세상에서 가장 튼튼한 성(System)을 지을 수 있으니까요!

“좋아, 엔진 테스트가 중요하다는 건 알겠어. 근데 그건 언제, 어떻게 하는 건데?”

좋은 질문입니다! 단위 테스트는 정해진 날에 한 번 하고 끝내는 이벤트가 아니에요.

언제? 개발자가 기능 개발을 끝낸 ‘직후’, 그리고 여러 부품을 조립하는 통합 테스트 ‘전’에 반드시 끝내야 하죠. 개발이 진행되는 동안 계속 반복되는 활동입니다.

어떻게? 개발자 ‘박 과장’이 V8 엔진(새 프로그램!)을 완성한 상황을 예로 들어볼게요.

박 과장은 엔진을 테스트 벤치에 올리고, 정상 작동할 때, 연료 대신 물을 넣었을 때, 장시간 공회전할 때 등 다양한 시나리오를 꼼꼼히 점검하기 시작합니다.
아니나 다를까, RPM을 올리자마자 엔진에서 미세한 떨림이 발견됩니다! 원인은 작은 부품의 조립 불량. 박 과장은 즉시 부품을 바로잡고, 처음부터 모든 테스트를 다시 수행하죠.
그리고 마침내 모든 테스트 케이스에서 ‘완벽’ 판정을 받은 후에야, 박 과장은 만족스러운 미소를 짓습니다. “좋아, 이 엔진, 이제 출고해도 되겠어!”

이것이 바로 개발자가 자신의 코드 품질을 책임지는, 살아있는 SAP 단위 테스트의 현장입니다.

많은 분들이 단위 테스트와 그 다음 단계인 통합 테스트를 헷갈려 하시는데요. 자동차 비유로 그 결정적인 차이를 확실하게 짚어 드릴게요.

둘은 목적부터가 완전히 다르답니다!