TDD

TDD란?

Test Driven Development의 약자로, 테스트 주도 개발이라는 뜻이다.

테스트 주도 개발이란 건 테스트를 먼저 하고 코드 구현은 그 다음에 한다는 의미이다.

 

 

TDD 개발 방식

실패하는 테스트 → 실패하는 테스트를 성공할 만큼의 기능 구현 → 성공하는 테스트
→ 리팩토링 → 실패하는 테스트와 성공하는 테스트 확인

 

유효한 패스워드인지 검증하는 방식을 예로 들면 다음 과정과 같다.

1. 패스워드가 특수문자를 포함하면서 알파벳 소문자를 포함하는지 테스트, 검증, 리팩토링 단계 반복
2. 패스워드가 특수문자 + 알파벳 소문자 + 알파벳 대문자를 포함하는지 테스트, 검증, 리팩토링 단계 반복
3. 패스워드가 특수문자 + 알파벳 소문자 + 알파벳 대문자 + 숫자를 포함하는지 테스트, 검증, 리팩토링 단계 반복
4. 패스워드가 특수문자 + 알파벳 소문자 + 알파벳 대문자 + 숫자를 포함하면서 8 ~ 20 길이(length)를 만족하는지 테스트, 검증, 리팩토링 단계 반복

 

 

TDD 특징

• 모든 조건에 만족하는 테스트를 먼저 진행한 뒤, 조건에 만족하지 않는 테스트를 단계적으로 진행하면서 실패하는 테스트를 점진적으로 성공시켜나감
• 테스트 실행 결과가 'failed'인 테스트 케이스를 지속적으로 그리고 단계적으로 수정하면서 테스트 케이스 실행 결과가 'passed'가 되도록 만듬
• 테스트가 'passed' 될 만큼의 코드만 우선 작성
• 실패하는 테스트 → 실패하는 테스트를 성공할 만큼의 기능 구현 → 성공하는 테스트
  → 리팩토링 → 실패하는 테스트와 성공하는 테스트 확인 흐름을 반복
• 실제 TDD 방식으로 잘 진행된다면, 테스트와 기능 구현, 리팩토링까지 빠르게 진행이 가능

 

 

TDD의 장점

• 테스트를 통과 할 만큼의 기능을 구현하기 때문에, 한번에 많은 기능을 구현할 필요가 없다.
• 단순한 기능에서 복잡한 기능으로 확장 되기 때문에, 그때 그때 검증을 빼먹지 않고 할 수 있다.
• 그때 그때 리팩토링을 빠르게 진행하기 때문에, 리팩토링의 비용이 상대적으로 적어진다.
• 항상 테스트 케이스가 존재하기 때문에, 기존 코드를 수정 하더라도 상대적으로 안전하다.
• 리팩토링을 통해 꾸준히 코드를 개선하기 때문에, 코드의 품질을 일정 부분 유지할 수 있다.
• 수정 결과를 그때 그때 확인할 수 있기 때문에, 잘못된 코드가 남아있을 가능성이 상대적으로 줄어든다.
• 결과적으로 야근 시간이 줄어들 수 있다.

 

 

TDD의 단점

• 익숙한 개발 방식은 아니기 때문에, 어려울 수 있다.
• 테스트 코드 작성에 부정적인 개발자에게는 좋지 않은 방식일 수 있다.

 

 

TDD 개발 방식은 함께 하는 팀원들 간에 사전 협의가 되어야 한다. TDD 방식에 대한 논의가 필요하고, 팀원들 각자가 TDD를 수용하고, 적용해 보려는 합의가 필요하다.

 

https://yoojin99.github.io/cs/TDD/

 

추가

• 애자일 소프트웨어 개발에 대해
  • https://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C
• TDD에 대해
  • https://www.simform.com/blog/what-is-tdd/
  • https://ko.wikipedia.org/wiki/%EC%BC%84%ED%8A%B8_%EB%B2%A1
  • https://ko.wikipedia.org/wiki/%ED%85%8C%EC%8A%A4%ED%8A%B8_%EC%A3%BC%EB%8F%84_%EA%B0%9C%EB%B0%9C