TDD란?

테스트 주도 개발(Test Driven Development) 에 대한 프로그래머들의 의견은 늘 엇갈렸습니다.

TDD의 실효성을 업무로 경험한 사람들은 TDD를 더 효과적으로 실무에 적용하기 위해 고민을 합니다.

반면, 회사마다 일하는 방식이나 처한 업무 환경이 다르고 편차가 있다보니, 일각에서는 실무에서 TDD를 사용하는 건 사실상 현실과 괴리감이 크다는 의견도 있습니다.

지금부터 TDD가 무엇인지 알아봅시다.

 

TDD

실제 동작하는 코드를 작성하기 전에, 테스트를 먼저 작성함으로 개발의 흐름을 테스트로 끌고 가는 개발 방법입니다.

개발자는 먼저 자신이 구현할 기능에 대해서 테스트를 작성하고, 테스트를 통과하는 코드를 작성함으로 수행 결과가 보증된 소프트웨어를 개발해 갑니다.

반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고, 이를 통과하는 코드를 구하는 단계를 반복하여 구현하게 됩니다.
짧은 개발 주기의 반복에 의존하는 개발 프로세스입니다.

 

TDD 개발주기

 

 

Write a failing test

단계에서 실패하는 코드를 먼저 작성합니다.

Refactor

단계에서는 테스트 코드를 성공시키기 위한 실제 코드를 작성합니다.

Make the test pass

단계에서는 중복 코드 제거, 일반화등의 리팩토링을 수행합니다.

 

https://medium.com/@ankitatejani84/what-is-tdd-e8f43d69cc8f

‘단위 테스트 작성 → 단위 테스트 실행 → 운영 코드 작성 → 단위 테스트 실행 → 설계 개선(리팩토링) → 단위 테스트 → … ‘
위 프로세스를 반복합니다.

 

중요한 것은 실패하는 테스트 코드를 작성할 때까지 실제 코드를 작성하지 않는 것과,

실패하는 테스트를 통과할 정도의 최소 실제 코드를 작성해야하는 것입니다.

이를 통해 실제 코드에 대해 기대되는 바를 보다 명확하게 정의 함으로써 불필요한 설계를 피할 수 있고, 정확한 요구 사항에 집중할 수 있습니다.

 

테스트 코드를 왜 작성해야할 까요?

1. 피드백을 빠르게 받아볼 수 있습니다.

개발 프로세스에서는 보통 '인수 테스트'라고 하는데, 이미 배치된 시스템을 대상으로 클라이언트가 의뢰한 소프트웨어가 사용자 관점에서 사용할 수 있는 수준인지 체크하는 과정에서 문제를 발견될 수 있습니다.

해당 문제를 해결하는 데, 적지않은 리소스가 필요할 것입니다.

 

이럴 때, TDD를 사용하면? 기능 단위로 테스트를 진행하기 때문에, 코드가 모두 완성되어 프로그래머의 손을 떠나기 전에 기능에 대한 피드백을 받을 수 있습니다.

 

2. 코드의 불안정성을 개선하여 생산성을 높일 수 있습니다.

테스트 주도 개발이다보니, 코드가 내 손을 떠나, 사용자에게 도달하기 전에 문제가 없는지 더 세밀하게 확인할 수 있어, 코드가 지닌 불안정성과 불확실성을 지속적으로 해소해줍니다.

 

3. 오버 엔지니어링을 방지합니다.

프로그래머들은 간혹 계획하지 않았던 코드를 추가하여, 오버 엔지니어링하는 경우가 있습니다.

하지만, TDD 프로세스를 이용하면, TDD의 원칙 중 하나가 테스트를 통과하기 위한 최소한의 코드만 작성 및 개선 해야한다는 원칙로 해야한 다는 것입니다. 기능 단위로 테스트를 진행하기 때문에 문제가 발생되지 않은 코드에 영향을 줄 수 있는 오버 코딩을 하지 않습니다.

 

4. 개발 과정이 테스트코드로 히스토리에 남습니다.

테스트 코드를 작성하는 과정에서 히스토리가 남아, TDD를 통한 테스트 코드를 트래킹하면서 과거에 어떤 인과관계로 의사결정을 했는지 확인하기 용이합니다.

 

 

 

TDD 프로세스 장단점?

장점

1. 객체 지향적인 코드 개발
2. 설계 수정시간의 단축
3. 유지보수(리팩토링)의 용이성
4. 테스트 문서의 대체가능

단점

1. 사전준비 기간
2. 생산성 저하

 

TDD  여러 의문점

TDD는 무조건 해야할까?

그렇지 않습니다

위에서 언급한 부분입니다. TDD가 현재 가지고 있는 논란처럼 모두에게 필요한 것은 아닙니다.

하지만, 프로그래머가 코드를 작성해 기능 하나를 추가할 때마다, 시간이 늘어난다고 하면?

TDD는 굉장히 비효율적으로 느끼게 될것입니다.

왜냐하면, TDD를 사용할 때 초기 비용이 하지 않을 때에 비해 크기 때문입니다.

물론 TDD를 사용했을 때, 초기 비용은 크지만? 시간 대비 비용이 더 커지지 않고 일정하게 유지하게 됩니다.

따라서, TDD를 위한 환경세팅이 이미 잘 되어있는 업무환경일 시, TDD를 사용하는 편이 장기적으로 효과적이니 상황에 맞게 해당 프로세스를 이용하는 게 좋을 거 같습니다.

 

TDD는 버그를 없애줄까?

그렇지 않습니다

TDD 프로세스를 이용하면, 박멸을 하진 못하지만 사용하면 더 많은 버그를 사전에 발견할 수 있습니다.

프로그래머가 작성한 코드가 사용자에게, 도달하기 전에 혹은 전체 코드를 완성하기 전에?

기능 단위로 문제를 개선할 수 있게끔, 빠른 피드백을 통하여 효과적으로 개선할 수 있는 기회를 갖습니다.

 

 

TDD는 항상 느릴까?

그렇지 않습니다

지금 위에 글을 보면, TDD를 사용하면 초기에 시간과 비용이 많이 든다고 언급을 하였습니다.

TDD 프로세서를 업무에 도입하면 업무속도가 느려진다고 느끼는 것에는 여러 이유가 있습니다.

1. TDD를 사용하기 위한 초기 자원이 미진하여 속도가 나지 않은 경우
2. 회사에서 여러 프로그래머가 협업하는 경우, TDD를 사용하기 위한 업무 프로세스가 익숙하지 않아 느려지는 경우
3. 코드 작성에 대한 부담감

등등. 다양한 요인이 있지만,

업무 환경에 익숙해지고, 그러한 환경이 주어진 곳이라면 무조건적으로 느리다고 할 수 없을 거 같습니다.