왜 TDD를 하고, 어떻게 TDD를 하면 좋을지

TDD, 왜 그리고 어떻게

• 정의
• 이유
• 방법

정의

TDD(test-driven development, 테스트 주도 개발)는 소프트웨어 개발 방법론 중의 하나

먼저 요구사항을 검증하는 자동화된 테스트 케이스를 작성 후, 테스트 케이스를 통과하기 위한 최소한의 코드를 생성하는 방식의 프로그래밍 방법

이유

Reduce debugging costs

애플리케이션은 좋은 코드와 설계를 갖추더라도 항상 결함이 존재

즉, 버그는 항시 발생하고 개발자는 결함을 해결하기 위한 디버깅 작업 필요

테스트는 결함을 최소화 → 디버깅에 필요한 자원 감소 → 비즈니스 로직 집중 → 생산성↑

Relieve anxiety about changes

애플리케이션에서 기능은 단일 요소가 아닌 여러 요소들이 상호작용을 통해 구현되기 때문에, 하나의 요소에 대한 수정이 어떤 기능에 영향을 미칠지 미리 예측하거나 예방 불가능

요구사항이 변경되어 기존 코드를 수정하거나 더 나은 코드를 위해 리팩토링 시, 테스트를 통해 예상하지 못한 버그를 미리 확인 및 수정하고, 서비스의 지속가능한 개발 보장

Neat documentation

좋은 코드란 잘 읽히는 가독성 높은 코드를 의미

서비스 복잡도가 늘어나면 코드 복잡도도 따라서 증가

따라서 유지보수 측면의 용이함을 얻기 위해 코드의 문서화 필요

테스트를 작성하면서 명세를 함께 작성하고, 코드의 실제 동작을 기술하여 문서화

Easy-to-test

좋은 코드란 변경하기 용이한 코드를 의미

TDD 방식으로 개발을 하면, 테스트하기 용이한 약한 결합도를 가지는 코드를 만들기 때문에 변경에 유연하고 재사용성이 높고 유지보수비용이 낮은 좋은 코드 작성 가능

Test Automation

TDD를 한 코드는 낮은 결합도와 높은 재사용성을 가지기 때문에 테스트 자동화를 하기에 쉬우며, 테스트 자동화를 통해 변경에 대한 자원 소모를 줄이고, 버그의 배포를 코드 병합 단계에서 확인 가능

방법

무작정 줄이는 게 아니라, 의미있고 명시적으로 작성

개발자는 중복되는 부분을 없애고자 보통 DRY(Don’t Repeat Yourself)한 코드를 작성

하지만 테스트 코드는 DAMP(Descriptive and Meaningful Phrases)하게 작성해야 함

코드의 중복을 줄이느라 테스트의 가독성이 떨어지면 테스트를 통한 코드의 문서화가 되지 못하기 때문

또한 테스트는 서로 독립적이고 격리되어 서로 영향을 주고 받지 않도록 작성(픽스쳐 활용)

내부 구현보다는 실행 결과를 검정하도록 작성

테스트 코드를 작성할 때 모의 객체를 사용(mock, spy, stub 등)

모의 객체를 사용하는 경우 내부 구현을 알아야 하는 경우가 많음

모의 객체의 맞춰 테스트를 작성하게 되면 내부 구현의 검증까지 되어서 얼핏 더 철저한 테스트라고 생각할 수 있으나, 오히려 리팩토링이나 요구사항 변경에 의한 로직 변경시 깨지기 쉬운 코드가 작성될 여지가 높음

내부 구현이나 비공개(private) 메소드들은 언제든 바뀔 여지가 있고 그 때문에 캡슐화 및 은닉을 하는데, 이러한 내부 구현 데이터를 다시 꺼내어 테스트하는 것은 좋지 않음

테스트 코드는 내부 구현보다 실행 결과 검증에 집중

가독성을 고려하여 읽기 좋게 작성

가독성이 낮고 의도가 불명확한 테스트 코드는 유지보수 비용 증가

좋은 테스트 코드는 개발자가 테스트를 이해하는 데 필요한 모든 정보를 테스트 케이스 본문에 담고 있는 코드

테스트 코드의 가독성을 높이기 위해서 테스트의 구조를 명확히 구분

테스트의 구조는 AAA(Arrange-Act-Assert, 준비-실행-검증)의 GWT(Given-When-Then) 패턴으로 구간을 나눠 작성하는 것이 좋음

만약 테스트 안에 너무 많은 양의 코드가 존재하는 경우, 코드 재사용의 목적으로 모듈화(테스트 팩토리, 빌더, 핼퍼 메소드)하여 가독성↑