Test Code Why? What? How?

테스트 코드를 왜 짜야 하는지, 무엇을 테스트해야 하는지, 어떻게 작성해야 하는지를 실제 나쁜 예제와 함께 체계적으로 짚는다. 카카오엔터 백엔드 플랫폼 개발자가 현장에서 겪은 시행착오를 담아 이론과 실전 괴리를 최소화한다.

핵심 포인트 - Why — 회귀 오류(Software Regression) 방지: 기능 추가·수정 시 기존 동작이 깨지는 문제를 자동으로 감지 - Test Pyramid: UI Test < Service Test < Unit Test 순으로 비중을 두어 피드백 속도와 안정성 균형 확보 - What — "Application Design(명세)을 테스트하라": 구현 세부가 아닌 공개 인터페이스(계약)를 검증해야 리팩토링에 강건한 테스트 작성 가능 - 정보은닉 원칙: 내부 구현이 바뀌어도 테스트가 깨지지 않으려면 외부 공개 인터페이스만 테스트해야 함 - SUT(System Under Test) 개념: 테스트 대상 단위를 명확히 정의하고 그 단위의 public API만 검증 - 나쁜 테스트 안티패턴 3종: ① 검증(assert) 없는 테스트 ② NotNull만 확인하는 피상적 검증 ③ 빈 컬렉션 여부만 확인하는 의미 없는 검증

상세 정리 - 회귀 오류는 변경의 부수효과(Side Effect)로, 테스트 없이 확인하려면 전체 시스템을 수동 검증해야 해 비용이 기하급수적으로 증가 - UI Test: 전체 사용자 흐름 검증, 느리고 불안정. Service Test: API·통합 경계 검증. Unit Test: 단일 함수·클래스 검증, 빠르고 안정적 - 인터페이스 기반 테스트는 내부 구현 변경(리팩토링)에 영향받지 않아 테스트 유지보수 비용 절감 - 나쁜 예제 ①: assert 블록이 없어 어떤 동작도 실패 시 캐치 불가 — 테스트 존재 자체가 의미 없음 - 나쁜 예제 ②: assertNotNull(result)만 있는 경우 — null이 아닌 잘못된 값도 통과해 실제 비즈니스 로직 오류를 감지 못함 - 나쁜 예제 ③: assertFalse(list.isEmpty())만 있는 경우 — 원소 개수를 검증하지 않아 의도와 다른 결과도 통과 - 올바른 검증: 기대값을 구체적으로 명시(assertEquals, assertThat 등)해 실제 비즈니스 명세 충족 여부 확인 - 내부 필드 직접 접근 테스트는 리팩토링 시 테스트가 먼저 깨지는 false negative 원인 - 테스트 코드도 프로덕션 코드와 동일 수준의 가독성·유지보수성을 갖춰야 함

왜 읽나: 테스트를 "있으면 좋은 것"이 아닌 설계 도구로 바라보는 관점 전환과 구체적인 안티패턴 예시를 통해 즉시 현장에 적용 가능한 기준을 얻을 수 있다.