[워밍업 클럽 3기 BE code] 2주차
테스트가 필요한 이유
사람이 애플리케이션을 실행하면서 잘 작동되는지 확인하는 작업은 놓칠 수도 있고, 시간이 오래 걸려 비효율적이다.
테스트 코드 작성의 이점
빠른 피드백: 코드 수정 후 바로 검증 가능
자동화: 반복적인 수동 테스트가 불필요
안정성: 코드 변경이 발생해도 기존 기능이 정상 동작하는지 보장
디버깅 용이: 문제 발생 시 원인 파악이 쉬움
단위 테스트
작은 코드 단위를 독립적으로 검증하는 테스트 → 검증 속도가 빠르고 안정적이다.
관련 라이브러리
JUnit5: 단위 테스트를 위한 테스트 프레임워크
AssertJ: 테스트 코드 작성을 원활하게 돕는 라이브러리
수동 테스트 vs 자동화된 테스트 비교
수동 테스트
사람이 직접 성공/실패를 판단
실수 가능성 높음
반복이 어려움
시간이 오래 걸림
자동화된 테스트
시스템이 자동으로 판단
실수 가능성 낮음
반복이 쉬움
소요 시간이 짧음
자동화된 테스트를 활용하면 수동 테스트의 한계를 극복할 수 있다.
자동화 테스트를 작성하면 테스트 결과만 확인하면 되므로 빠르고 정확하다.
테스트 케이스 세분화하기
해피 케이스(정상 동작)*만 작성하지 않고 예외 케이스(예상하지 못한 상황)도 함께 테스트해야 한다.
TDD (Test Driven Development)
프로덕션 코드보다 테스트 코드를 먼저 작성하여, 테스트가 구현 과정을 주도하도록 하는 개발 방법론
빠른 피드백을 통해 코드 품질을 높이고, 유연한 설계를 가능하게 함
TDD의 장점
내 코드의 피드백을 빠르게 받을 수 있음
리팩토링이 쉬워짐 → 테스트가 있으므로 기존 기능이 정상 동작하는지 보장됨
테스트 가능한 코드 설계 → 단일 책임 원칙(SRP)에 맞게 코드 구조를 고민하게 됨
디버깅 시간 단축 → 기능 개발 중 발생하는 문제를 사전에 방지할 수 있음
기능 구현 방식 비교
방식 장점 단점
선 기능 구현, 후 테스트 작성
장점 : 구현이 직관적이고 빠르게 가능
단점 : 테스트 누락 가능성, 특정 케이스만 검증, 잘못된 구현 발견 지연
선 테스트 작성, 후 기능 구현 (TDD)
장점 : 테스트가 어려운 영역을 미리 발견하여 설계를 개선할 수 있음
단점 : 초기 개발 속도가 다소 느릴 수 있음
TDD의 핵심 원칙: Red → Green → Refactor
1⃣ Red (실패하는 테스트 작성)
테스트 코드를 먼저 작성하고 실행 → 아직 기능이 없으므로 테스트가 실패해야 한다.
2⃣ Green (기능 구현하여 테스트 통과)
테스트가 통과하도록 최소한의 기능을 구현한다.
3⃣ Refactor (리팩토링)
중복 제거, 코드 개선을 통해 더 나은 구조로 변경한다.
리팩토링 후에도 테스트가 통과하는지 확인한다.
테스트는 [문서]다
테스트 코드는 해당 기능의 동작을 설명하는 문서 역할을 한다.
@DisplayName을 활용하여 테스트 목적을 명확히 하자.
@DisplayName("회원 가입 시 이메일이 중복되면 예외가 발생한다")
@Test
void 회원가입_이메일중복_예외발생() {
// Given
// When
// Then
}생각 정리
테스트의 중요성에 대해서는 인지하고 있었지만 테스트 코드 작성이 항상 귀찮고 어렵게 느껴졌었다. 하지만 테스트 코드를 작성하고 결과를 확인하는 과정 자체가 더 나은 프로덕션 코드를 만드는 과정이 될 수 있다는 것을 깨달았다.
특히 TDD의 경우에는 기능이 없는데 테스트 코드를 먼저 작성하는게 이해가 안 됐었는데 테스트를 실패하는 최소한의 기능을 먼저 만들고 점진적으로 더 나은 코드 작성 및 설계를 할 수 있도록 유도하는 과정이라는 것을 알게 되었다.
강의
댓글을 작성해보세요.
