10/6 TIL 기술면접 TDD

이승준·2023년 10월 6일

TDD란 ?

TDD란 Test Driven Develpment의 약자로 '테스트 주도 개발' 이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로, 엔지니어 켄트 벡(Kent Beck)에 의해 고안되었다. 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

TDD를 쓰는이유

3단계의 개발주기를 반복적으로 진행되면서 자연스럽게 코드의 버그는 줄어들고 소스의 코드는 간결해진다. 또한 테스트 케이스 작성으로 인해 자연스럽게 설계가 개선됨으로 재설계 시간이 절감될 수 있다.

3단계의 개발주기

테스트 작성 (Red): 개발자는 기능이나 모듈에 대한 테스트 케이스를 작성합니다. 이 테스트 케이스는 아직 작성되지 않은 코드를 테스트하는 데 사용됩니다. 이 단계에서는 테스트가 실패하는 것이 정상입니다.
코드 작성 (Green): 테스트 케이스를 통과하기 위한 최소한의 코드를 작성합니다. 즉, 테스트를 통과하는 코드를 구현하는 것이 목표입니다.
리팩토링 (Refactor): 작성한 코드를 개선하고 정리합니다. 코드를 더 효율적으로 만들거나 가독성을 높이는 등의 작업을 수행합니다. 이때도 테스트가 통과해야 합니다.

TDD의 장점

자동화된 테스트: 테스트 케이스를 먼저 작성하므로 코드 변경 시 자동으로 테스트를 실행하여 버그를 조기에 발견할 수 있습니다.
문서화: 테스트 케이스는 코드의 동작 방식을 문서화하고 코드의 의도를 명확하게 설명합니다.
리팩토링 지원: 코드를 안정적으로 개선하고 수정할 수 있도록 도와줍니다. 테스트가 통과하는 한, 리팩토링은 자신있게 수행할 수 있습니다.
개발 생산성 향상: 버그를 줄이고 코드의 품질을 향상시키며, 개발 프로세스를 빠르게 반복할 수 있게 합니다.
의사소통 도구: 팀원들 간에 코드의 기능과 동작에 대한 공유와 의사소통을 쉽게 만듭니다.

TDD의 단점

생산력 저하: 한번 개발할 코드를 두번이상 작성해야 하기 때문에 생산력은 떨어진다. 또한 단순 개발이나 단발성 프로젝트에서는 TDD 에서 복사 붙여넣기를 자주 사용하게 되고 중복된 테스트코드는 비효율적일 수 있다.

좋은 테스트 코드를 위한 'FIRST 규칙'

Fast 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 한다.
만약 테스트가 느리다면 개발자는 테스트를 주저하게 되고 자주 검증하지 않은 소스코드는 그만큼 버그가 발생할 확률이 높아진다.

Independent 각각의 테스트는 독립적이며 서로 의존해서는 안된다. 테스트에 필요한 데이터는 테스트 내부에서 독립적으로 사용해야 한다. 만약 데이터가 서로에게 의존하면 테스트 하나가 실패할 때 나머지도 잇달아 실패하므로 원인을 진단하기 어려워지기 때문이다. 때론 데이터의 존재 여부를 찾는 테스트가 있는 경우엔 해당 데이터는 테스트 내부에서 생성되어야 하며 나중에 테스트에 영향을 미치지 않도록 제거해야 한다.

Repeatable 어느 환경에서도 반복 가능해야 한다. 여기서 환경은 네트워크 나 데이터베이스에 의존하지 않는 환경을 뜻한다. 결론적으로 인터넷이 되든 안 되든 데이터베이스에 접속하든 안 하든 언제 어디서나 테스트를 할 수 있어야 한다. 환경에 의존하지 않는 테스트가 실패할 수 있는 유일한 이유는 오로지 테스트할 클래스 또는 메소드가 제대로 작동하지 않기 때문이다.

Self-Validating 테스트는 성공 또는 실패로 boolean값으로 결과를 내어 자체적으로 검증되어야 한다. 테스트의 검증은 수작업이 아닌 자동화가 되어야 하는데 테스트가 실행될 때마다 메서드 출력이 올바른지를 확인하는 것은 개발자가 결정해서는 안 된다.

Timely 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 한다.