[Interview] TDD 란 무엇인가요

TDD (Test-Driven Development)

● 테스트 주도 개발, 실제 기능 코드 작성 전에 실패하는 테스트 케이스를 먼저 작성하고
   그 테스트를 통과시키기 위해 최소한의 코드를 구현한 후 리펙토링하는 반복적인 개발 방법론입니다.

 

● Red (테스트 실패), Green (테스트 통과), Refactor (코드 개선) 3가지의 사이클로 진행되며,
  요구사항에 맞게 코드를 작성하고 동시에 테스트 커버리지를 높입니다.

테스트 커버리지 (Test Coverage) - 시스템 또는 소프트웨어의 테스트를 논할 때 얼마나 테스트가 충분한가를 나타낸 것

 

TDD를 한다면 장점은 무엇인가요

● 코드 품질, 모듈성이 향상합니다. 

  - TDD를 수행한 코드는 테스트를 기준으로 모듈화되며, 테스트 케이스가 코드의 의도와 기능을 명확히 설명해줍니다.

예 : 쇼핑 사이트의 할인 계산 기능을 구현할 때, 할인율과 계산 결과에 대한 테스트 케이스를 먼저 작성하여 코드가 복잡해지더라도 각 모듈이 독립적으로 검증되어 유지보수가 용이해집니다.

 

● 버그를 조기에 발견할 수 있으며, 디버깅 시간을 단축시킬 수 있습니다.

  - 개발 과정에서 지속적으로 테스트를 실행함으로써 새로운 기능이나 변경사항이 기존 기능에 미치는 영향을
    즉시 확인할 수 있습니다.

예 : 은행 시스템에서 계좌 이체 기능을 구현할 경우, 송금 전 잔액 확인과 송금 후 잔액 업데이트에 대해 미리 작성한 테스트가 있어, 예기치 않은 계산 오류나 논리적 버그를 신속히 발견할 수 있습니다.

 

● 안전하게 코드를 리펙토링 할 수 있습니다.

  - 테스트가 모든 기능과 경계 상황을 커버하기 때문에, 기존 코드를 리펙토링 하더라도 테스트가 실패하지 않으면
    기능이 보장되며 이를 확신할 수 있게 됩니다.

예 : 복잡한 비즈니스 로직을 단순화하기 위해 코드를 재구조화 해야할 때, 기존 테스트 케이스를 모두 통과한다면 코드 구조는 변경되었더라도 기능의 일관성이 유지된다는 것을 보장받을 수 있습니다.

 

● 명확한 요구사항을 확인할 수 있으며, 문서화의 역할도 가능합니다.

  - TDD에서 작성된 테스트 케이스 자체의 코드의 사용법과 요구사항을 문서화하는 역할을 해주기 때문에
    개발팀 내외의 소통을 원할하게 만들어줍니다.

예 : 신규 기능에 대해 모든 부서가 회의를 할 때 "이러한 상황에서 이러한 결과가 나온다" 라는 내용의 테스트 코드를 제시함으로써, 향후 다른 개발자가 기능을 파악하거나 확장할 때 참고 자료로 활용할 수 있습니다.

 

정리하자면

  TDD는초기 설계부터 코드 구현, 유지보수까지 전반적인 개발 사이클에 긍정적인 영향을 줍니다. 개발자들이 보다 안정적이고 깨끗한 코드를 작성할 수 있게 도와줍니다. 생각나는 단점으로는 처음 TDD를 접하고 이를 습관화하기까지가 어려운 점으로 꼽을 수 있을 거 같습니다.