테스트 주도 개발:
테스트가 개발을 이끌어 나간다
반복 테스트를 이용한 소프트웨어 방법론으로, 테스트를 먼저 만들고 이를 통과하기 위한 코드를 만들고를 반복하면서 제대로 동작하는지에 대한 피드백을 적극적으로 받는 것.
보통의 소프트웨어 개발 방식은 코딩을 다 끝나고 난 후 테스트를 한다.
이것의 순서를 바꾸는 것이 TDD를 적용한다고 볼 수 있다.
TDD와 일반적인 개발 방식의 가장 큰 차이점은 테스트 코드를 작성한 뒤에 실제 코드를 작성한다는 것이다.
예를 들어, 건물을 지을 때 벽돌을 쌓는 방법을 떠올려 봤을때 벽돌을 쌓을 때는 벽돌을 얼마만큼 쌓을 건지 특정영역에 실로 표시를 해놓고 벽돌을 쌓다가 실까지 벽돌이 채워지면 쌓는 것을 중지한다.
TDD 로 비유하면 공간에 실로 영역을 표시하는 것을 "테스트 코드"
실제 벽돌을 쌓는 것은 "실제코드"
벽돌을 쌓을 때 벽돌이 비뚤어지는지 정확히 쌓이는지 실에 의해서 판단이 가능한 것과 같은 뜻으로 테스트 코드
는 실제 코드
가 나아가야 할 방향을 알려주고 있는 것이다.
만약 벽돌이 조금 비뚤어지게 쌓였다면 반듯하게 다시 잡아가게 되는데 이것은 리팩토링
비유할 수 있다.
(리팩토링은 소스코드의 기능은 유지한 채로 소스코드의 디자인을 개선해 나가는 방법이다)
실패의 이유는 운영 코드가 아직 변경되지 않았기 때문이어야 하며 테스트 코드의 문제이면 안됨
추가된 테스트를 포함하여, 모든 테스트가 성공하게끔 운영 코드를 변경
테스트의 성공은 모든 요구사항을 만족했음을 의미
테스트 성공을 위한 최소한의 코드 변경만 진행
TDD를 반복하다 보면, 지루함을 느끼는 프로그래머가 많지만 TDD에서는 테스트 성공을 위한
최소한의 코드 그 이상을 변경하거나 추가하면 안됨 테스트 되지 않은 코드가 중간에 추가되면, 이후 리팩토링 등의 다른 프로세스에서 어떤 부작용을 가져올지 알 수 없기 때문
중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과, 실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야 하는 것이다. 이를 통해, 실제 코드에 대해 기대되는 바를 보다 명확하게 정의함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있다.
몸에 체득한 것이 많을 수록 바꾸기 어렵다.
오히려 개발을 별로 해보지 않은 사람들에겐 적용하기가 쉽다.
만약 어떤 부분에 대한 코딩을 여러번 해봤고 결과가 어떻게 나올지 알 거 같다 하면 TDD하지 않아도 됨.
또한 TDD를 했을 때 얻는 것이 적다면 TDD를 하지 않아도 됨.
1. 처음해보는 프로그램 주제
2. 고객에 요구조건이 바뀔 수 있는 프로젝트
3. 개발하는 중에 코드를 많이 바꿔야 된다라고 생각이 되는 경우
4. 내가 개발하고 나서 이 코드를 누가 유지보수할지 모르는 경우
즉, 불확실성이 높을때 사용하면됨
피드백과 협력을 증진시키기 때문에 불확실성에 대해 대비를 하게 해준다.
장점 |
---|
보다 튼튼한 객체지향적인 코드생산
재설계 시간 단축
디버깅 시간의 단축
테스트 문서의 대체가능
추가 구현의 용이함
&
단점 |
---|
생산성↓:
처음부터 2개의 코드를 짜야하고, 중간중간 테스트를 하면서 고쳐나가야 하기 때문이다. TDD 방식의 개발 시간은 일반적인 개발 방식에 비해 대략 10~30% 정도로 늘어난다.
진입장벽:
TDD를 프로젝트에 도입하려면 TDD를 공부해야 하고 추가적으로 테스트 코드를 작성해야 하기 때문에 익숙치 않은 사람들은 1-2달에 적응시간 이 걸린다.
난이도:
TDD가 최소한의 객체지향 프로그래밍을 요구하는 이상 보통 1~2년 차 개발자라도 조금 어렵다는 생각이 들 수 있다
만약 자신이 TDD의 가능성을 본 사람이고 능숙해지고 싶다는 마음을 가졌다면 내공이 하루아침에 쌓이지 않는 것처럼 용기와 끈기를 가지고 부단히 노력해 보면 좋을 것이다
TDD(Test-Driven Development) 연습해보기 - 예제 1: Money (1) 1~8장
기술면접 TDD(Test-Driven-Development) 방법론에 대해서
Agile TDD(테스트 주도 개발)이란
TDD란? 테스트 주도 개발
TDD(Test-Driven Development)란?
D. 테스트 주도 개발