자, 스무번째인 'TDD'를 알아 볼 것이다.

이전 게시물과 같이 개발 방법론의 대한 개념이기 때문에 이론 중심으로 알아보았다.

TDD가 뭐에요?

'TDD'sms Test Driven Developing의 약자로 테스트 중심 개발이라는 뜻을 가지고 있다.

'테스트 중심 개발'은 소프트웨어 개발 방법론중 하나로 테스트 케이스를 작성하고 그에 맞는 코드를 작성하는 순서로 개발하는 방식이다.
TDD는 보통 사진과 같이 세 단계로 진행된다. Red, Green, Refactor 이라고도 한다.

TDD의 개발 과정

red, green, refactor 순으로 과정을 알아보았다.

1. Red: 빨간색 단계에서는 아직 구현되지 않은 기능을 테스트하는 작은 테스트 케이스를 작성한다. 이 테스트는 예상한 기능이 아직 구현되지 않았기 때문에 실패한다. 이는 코드가 "실패"한 상태를 나타내며, 이 단계에서 개발자는 아직 작성하지 않은 코드에 집중할 수 있다.

2. Green: 초록색 단계에서는 테스트를 통과하기 위한 최소한의 코드를 작성한다. 목표는 테스트를 통과하는 것뿐이며, 코드의 품질이나 구조에 대해서는 신경 쓰지 않는다. 이로써 코드는 테스트를 통과하고, 새로운 기능이나 기존 기능의 변경이 이루어진다.

3. Refactor: 리팩터링 단계에서는 작성한 코드를 개선하고, 중복을 제거하며, 구조를 개선하여 코드의 가독성과 유지보수성을 향상시킨다. 이 단계에서는 테스트 케이스가 그대로 유지되므로, 코드의 변경이 기능에 영향을 미치는지 여부를 확인할 수 있다.

TDD의 장점

1. 신뢰성 있는 코드: 테스트 케이스를 작성하여 기능이 예상대로 작동하는지 확인하기 때문에 코드의 신뢰성이 향상된다.

2. 더 나은 설계: 테스트 주도 개발은 코드를 작은 모듈로 분해하고, 각 모듈의 독립성을 유지하도록 유도하여 더 나은 소프트웨어 설계를 장려한다.

3. 자기 문서화: 테스트 케이스는 코드의 사용 예를 제공하므로, 코드를 읽는 사람들에게 도움이 된다.

4. 빠른 피드백: 개발자는 코드를 변경할 때마다 테스트를 실행하여 즉시 결과를 확인할 수 있다.

결론 - 느낀 점

이번에도 개발방법론에 대해서 알아보았다.

Test는 워낙 많이 해보는 단계라서 '엥 그냥 짜맞춘 개념아닌가?' 싶었다.

하지만 테스트를 중심으로 하여 각각의 테스트를 문서화하고 추적하기 쉽게 만들어
더욱 견고하게 만들고 체계적으로 개발하다 보니 퀄리티가 높아질 수 밖에 없는 개발 방법론이라고 느껴졌다.

이것을 회사가 아닌 개인적으로나 소규모로 개발을 하면 이 방법론으로 진행할 수 있을까 라는 생각도 든다.