[TDD] TDD 란 ?

최근 Unit Test 관련하여 스터디를 진행하고 있는데,

TDD 에 대해서 명확하게 개념을 정리하지 않은 것 같아 한번 간단히 정리해 보려고 한다.

---

우선,

TDD 란 무엇인가 ?

 

Test Driven Development. 테스트 주도 개발의 약자로,
테스트를 통해 개발을 이끌어 나가는 소프트웨어 개발 방법론.

 

소프트웨어를 개발할 때, 작은 단위의 테스트 케이스를 만들어 반복적으로 테스트를 진행하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현하는 방식이다.

 

개념부터 필자가 잘못 생각하고 있던 것이 있다.

TDD 를 기반으로  구현을 할 때, 테스를 기반으로 소프트웨어를 구현해야 한다는 것이다.

 

보통, 앱을 개발할 때, 테스트는 기능 구현이 끝나거나 일정한 부분의 개발을 완료 한 후 테스트를 통해 오류 및 문제를 해결한다.

하지만 TDD 기반으로 생각한다면, 위의 순서를 반대로 작은 테스트 단위로 구현을 하고 문제가 없으면 이 테스트의 단위를 크게 하여 원하는 기능을 구현하고, 앱을 구현하게 된다는 것이다.

 

여기서 정확히 알아야 할 TDD 의 개발주기는,

 

1. 실패하는 테스트를 추가한다.
2. 성공하는 테스트를 추가한다.
3. 테스트 성공을 유지하면서 구현된 설계를 개선한다.

 

가 된다.

 

전체를 만들고 기능 테스트 하는 것이 아닌,

테스트를 진행하면서 문제가 없음을 확인하고, 문제가 없는 부분을 유지하면서 덧붙이기를 하여 원하는 기능을 만들게 되는 것이다.

 

이 때, 1번 주기인 실패하는 테스트를 추가한다. 가 중요한 이유는, 테스트 코드가 정상적으로 동작함을 알기 위해서이다.

테스트를 실패하기 위하여 인위적으로 구현을 잘못하거나 해서는 안된다.

구현은 그대로 유지하되, 테스트 시 잘못된 데이터를 넣었을 때 정상적으로 테스트가 실패하는 것을 확인함으로써 해당 테스트 코드가 정상적으로 동작함을 알 수 있는 것이다.

 

이처럼 위의 개발 주기를 계속하여 반복하면서, 작은 기능부터 하나의 앱이 완성될 때 까지 반복하는 것이

TDD 테스트 주도 개발 방법론을 적용하게 되는 것이다.

---

TDD 가 무엇인지 알아보았으니,

TDD 의 장단점에 대하여 생각해보자.

 

우선, 단점으로는 

 

1. 개발 시간이 늘어나게 된다.
2. TDD 를 적용하기가 쉽지 않다.

 

이 외의 단점도 있겠지만, 크게봤을 때 단점으로는 이 2가지가 있는 것 같다.

 

개발시간이 늘어난다. 라는 단점은 단순하게 생각해도 알 수 있을 것이다.

처음부터 TDD 를 사용한 개발을 하더라도, TDD를 적용하지 않는 개발보다 시간이 더 오래 걸리게 될 것이다.

일정한 시간 내에 개발할 수 있는 물리적인 시간은 정해져있는데, 테스트 시나리오를 만들고 테스트를 진행하면서 개발을 하는 것 자체가 시간적으로 보았을 때 당연히 더욱 더 오래걸릴 것이다.

하지만, 프로젝트의 지속 시간이 길면 길수록, TDD를 사용하여 개발을 하는 것과 TDD를 사용하지 않는 것과의 개발속도의 차이는 점점 줄어든다고 한다.

 

TDD 적용이 쉽지 않다는 것은 테스트를 하기위하여 추가적으로 공부해야하는 것들, 최근에 필자가 공부하였던 Mockito, Truth 등 Unit Test를 위한 지식이 있어야 한다는 것도 있겠지만,

지금까지 TDD를 사용하지 않았던 개발 방식의 순서를 바꿔야 하기 떄문이다.

지금까지 대부분의 사람들이 해오던 방식은 기능을 구현하고 테스트를 하는 방식이었을 텐데, TDD를 도입하게 되면 테스트를 통해 다른 기능을 개발해야 하는 것이다.

즉, 지금까지 해왔던 것들과 반대되는 순서로 개발을 해야하기 때문에 이것들을 바꾸는 것이 생각보다 어렵다고 한다.

필자도 이렇게 개념을 공부하고 글을 쓰고있지만, 어떻게 개발을 해야할지 감이 잘 잡히지 않는다.

 

다음으로, 장점에 대하여 알아보자.

 

1. 결함이 줄어든다.
2. 추가 구현이 쉽다. (객체 지향적인 코드가 된다.)
3. 디버깅 시간이 단축된다.

 

이것들 외에도 상당한 장점들을 찾아 볼 수 있지만, 크게 느껴지는 3개만 작성했다.

 

결함이 줄어드는 것은, 아무래도 테스트를 통하여 개발을 진행하다보니 당연한 장점이 될 수 있다.

테스트를 진행하고, 테스트에 성공하는 것을 기반으로 기능을 쌓아올리는 방식이 되다보니 테스트가 실패하는 경우를 미리 찾아내어 수정할 수 있다.

 

추가 구현이 쉽다는 것은 하나의 작은 단위의 테스트를 진행하면서 쌓아 올리는 것이기 때문에, 필요한 부분을 제외하고 서로 다른 코드에 영향을 주는 가능성이 매우 낮아잔다.

즉, TDD 를 통해 개발을 진행하면 기능 별 모듈화가 이루어지게 되고, 명확한 곳에서만 상호작용이 이루어지기 때문에 추가적으로 기능을 구현할 때 많은 부분을 신경쓰지 않아도 된다.

 

마지막으로, 디버깅 시간이 단축된다는 부분은 2번 모듈화에 이어지는 내용이라고 생각한다.

실제 TDD를 사용하지 않는다면 문제가 발생하였을 때, 데이터의 문제인지 UI의 문제인지 그 외의 문제인지 등 다양한 문제 발생 요소를 확인하여 체크해야 한다.

하지만, TDD를 사용하였을 때는 어느 부분에서 문제가 발생했는지에 대해 쉽게 찾을 수 있게 된다.

---

TDD는 반드시 적용해야 하는 것은 아니지만,

확실히 적용했을 때의 이점이 더 많은 방법론이라고 생각한다.

 

기능을 개발하고 테스트를 하는것이 아닌,

테스트를 통해 하나씩 쌓아올려 기능을 개발한다는 것이 아직까지 명확하게 이해가 되지 않는 것 같다.

다양한 장점들이 있다는 것은 알겠지만,

단순한 기능을 개발할 때도 그냥 개발하는 것 보다 좀 더 많은 시간이 소요될 것이라고 생각을 하니 어떻게, 어디까지 TDD를 적용하여 개발하는 것이 좋을까? 라는 의문을 갖게 하는 것 같다.

 

추후, Unit Test 에 대한 공부를 하면서 위의 TDD 기반의 개발 방법론을 사용하여 간단한 샘플이라도 만들어봐야 할 것 같다.