Spring Boot TDD

"왜 TDD를 도입하려 할까?"

TDD 는 구현 설계의 관점이 아닌 제품 가치에 중점을 두어 바라볼 수 있기 때문이다. 여기서, 구현 설계란 소프트웨어 엔지니어가 요구사항을 이행하는 비즈니스 로직에 그친다.

예를 들어, 캘린더에 할 일을 표기하면 앞으로는 할 일을 마쳤는지에 대한 상태 값을 관리한다고 한다.

구현 설계에 따르면 할 일을 완료 했을 때 상태가 올바르게 변경이 되는지를 우선적으로 고려하게된다. 이는 기능이 정상 동작하는지를 우선적으로 생각하게 되어 사고의 확장이 힘들 수 있다.

제품을 바라보는 입장에서는 기능의 고민에서 더 나아가 "할 일을 정말 완료하지 않았는데 완료율을 채우려고 눌렀다면 어떻게 해야할까?" 처럼 사용자에게 제공 하는 기능이 제품을 사용하는 사용자의 입장에서 생각할 수 있다는 것이다.

"하지만, 우리는 왜 매번 TDD 도입에 실패할까?"

TDD에 대한 오해

1. 클래스를 작게 나누어야만한다.

구현 코드를 직접적으로 테스트 환경에서 사용하지 않고 인터페이스에 대해서만 테스트한다면, 내부 코드가 작든 크든 테스트에 미치는 영향은 없다.

클래스가 작을수록 유지보수에 용이한 것은 확실하나 이는 테스트와 무관하다.

1. 현대적인 아키텍처(클린 아키텍처, 헥사고날 등) 를 사용해야한다.

현대적인 아키텍처는 기존의 많은 문제점을 고안하여 개선된 버전으로 도입 시 테스트 작성 비용이 감소할 수 있다. 다만, 현재 팀과 프로젝트 코드 기반이 아키텍처 도입에 어려운 상황이라면 테스트 작성만을 목적으로 아키텍처 도입을 하는 것은 굉장히 무모하다.

1. SpringBootTest 처럼 컨테이너를 사용하는 테스트는 몹시 느리다.

SpringBootTest 는 당연히 프로젝트의 빈 객체를 컨테이너로 모두 관리하고 있기 때문에 퓨어 자바의 객체만을 가지고 테스트 하는 것 보다 느리다.

다만, SpringBootTest 는 모든 테스트 코드에서 새롭게 빌드 되지 않고 싱글턴을 활용해 구성을 통합하면 최초의 1번만 또는 정말 필요한 환경만 빌드 되기 때문에 무조건 오래 걸린다고 볼 수 없다.

위와 같이 TDD를 도입하기 전 굉장히 높은 러닝커브와 주변에서 하는 말을 비추어 보았을 때 굉장히 많은 오해를 낳았다.

하지만 그 오해는 주관적인 것으로 실제 그렇지 않은 경우도 많다는 것이다.