루퍼스 1주차 WIL (TDD & 테스트 가능한 구조)

테스트 코드 왜 필요할까요

TDD (Test Driven development)를 적용하다 보니 어떤 장점을 가지고 사용하는지를 알게 되었다. 

 

테스트 가능한 구조를 위한 리팩토링

 

MVC 구조

가장 와닿았던 부분은 테스트 코드를 작성하기 쉬운 구조를 만들기 위해서는 구현 단계에서부터 객체지향 설계와 의존 관계를 고려해야 한다는 점이다.

 

즉, 도메인 로직은 반드시 도메인 내부에 위치해야 하며, 이를 통해 도메인만 독립적으로 단위 테스트를 수행할 수 있다.

또한 Repository와 같은 외부 의존성은 인터페이스로 분리해 두면, 실제 DB 대신 Fake 객체를 활용한 In-Memory 방식으로 테스트를 구성할 수 있어 외부 환경에 의존하지 않고도 실행 흐름과 상태 변화를 안정적으로 검증할 수 있다.

 

Autowired 보단 생성자 주입

결국 테스트가 편리한 구조를 만들기 위해서는 외부 의존성 분리뿐 아니라 의존성 주입 방식도 중요하다.

@Autowired 필드 주입은 Spring 컨테이너에 의존하기 때문에 순수 JUnit 환경에서는 의존성을 명확하게 주입하거나 교체하기 어려워 테스트 코드를 작성한다면 생성자 주입이 의존성을 명확하게 드러내고, Fake나 Mock 주입을 쉽게 만들어 단위 테스트에 더 적합하다.

테스트 코드는 자산이다

테스트 코드는 요구사항의 자산이 될 수 있다. 

만약 지금 테스트 코드 없이 회원가입을 만들어라라고 한다면 대부분의 개발자는 잘 만들 것이다 (AI와 함께라면)

하지만 이 회원가입 코드를 1년 뒤에 본다면? 한 번에 이해할 수 있을까? 로직이 쉽다면 이해가 잘 되겠지만 복잡한 비즈니스 로직을 테스트 코드 없이 본다면 구현부를 매일 까보는 일을 반복하게 될 것이다.

 

TDD를 학습하면서 테스트 코드가 무조건 좋다는 것은 아니고 객체지향 설계에 욕심이 있고 복잡한 비즈니스 로직을 한 번에 풀고 싶다면 테스트 코드를 작성해서 구현부 유지보수나 요구사항을 편리하게 관리할 수 있다는 것을 느꼈다.