우선 아래 글은 정보 및 주관이 섞인 글입니다. 참고 부탁드립니다 >_O
면접을 보다가 받았던 과제에서 TDD 를 사용해서 작업해달라고 요청받았던 적이 있었다.
이전부터 내용은 알고 있었는데 정리가 잘 안되고 사용도 많이 못해봐서 이렇게 글이라도 적어본다! ( 이래야 다시 보고 하겠지라는 마음으로! )
TDD 가 뭐야??
테스트 주도 개발(Test-driven development, TDD)은 매우 짧은 개발 사이클을 반복하는 소프트웨어 개발 프로세스 중 하나이다. 우선 개발자는 바라는 향상 또는 새로운 함수를 정의하는 (초기적 결함을 점검하는) 자동화된 테스트 케이스를 작성한다. 그런 후에, 그 케이스를 통과하기 위한 최소한의 양의 코드를 생성한다. 그리고 마지막으로 그 새 코드를 표준에 맞도록 리팩토링한다. 이 기법을 개발했거나 '재발견' 한 것으로 인정되는 Kent Beck은 2003년에 TDD가 단순한 설계를 장려하고 자신감을 불어넣어 준다고 말하였다.
출처: 위키피디아
아래에서 길고 장황하게 설명하겠지만, 내가 TDD 에 대해 이해하고 내가 설명한다면 이렇게 설명할거다.
한 제품을 생산하는데 있어서 설계를 하고 설계대로 만들었는데, 테스트를 하다보니 '어? 이게 예상과 다르네??' 하면 다시 뜯어야하고 고치고 하는데에 시간과 에너지가 더 든다. 그러니 미리 테스트 하면서 설계대로 잘 만들자!
난 이 정의를 몇 번째 보는지 잘 모르겠다... 너무 많이 봤어 이 정의!
사실 이렇게 늘 봐도 잘 모르겠는 것에 대해 작성하는 건 내가 언젠가 또 다시 검색하고 또 찾을 때 내 블로그를 보기 위함이기도 하고 나처럼 정말 봐도 봐도 모르는 사람들에게 언젠가 도움을 줄 수 있지 않을까 해서 글을 적어본다.
TDD(Test-Driven-Development) 라는 것에 대해 내용을 좀 더 쉽게 생각해보자. 이 용어 그대로~
개발을 하는 것에 있어 테스트가 주가 되게끔 하여 개발한다는 의미로 해석된다.
아래는 기존에 우리가 흔히 아는 방식을 그려봤다.
그리고 TDD를 적용하였을 때의 방식을 그려봤다.
이렇게 봤을 때 차이점이 보이는가??
기존엔 설계를 하고 바로 개발을 진행하고 테스트를 진행한 후 이슈가 생기는 경우 다시 설계를 고치는 상황이 나와서 비교적 오랜 시간이 걸린다. 하지만 TDD 를 통한다면, 설계 후 테스트를 먼저 진행하는 코드를 간결히 생성하고 테스트 후 원치 않는 형식의 결과를 받게 되면 직전 단계인 설계 단계를 다시 수정하고 소스를 재수정하는 과정을 거친다.
위 둘을 비교했을 때, TDD 를 적용 시 고치는 비용이 적게 들고, 설계 수정 시간의 단축효과를 본다고 한다.
과연 우리는 각자의 회사에서 TDD를 하려면?? 어떤 점을 어필해 볼 수 있을지 아래 장점들에서 뽑아봅시다.
TDD의 장점
첫 번째, 객체지향적인 코드를 짤 수 있어요!!
이전처럼 먼저 Product 코드를 작성하는 게 아닌 테스트 코드를 작성하면서 좀 더 명확한 기능과 구조를 설계할 수 있다. 이유는 테스를 위해 복잡한 기능을 한 함수에 모두 구현하게 되면 복잡하고, 오래 걸리고, 코드 수정하려고 다시 그 긴 코드를 읽어야하기에 목적에 맞지 않게 된다. 이런 류의 코드를 재사용하게 된다면 복붙하고싶어지지 않을까 생각합니다. 그러므로 코드를 복잡하지 않게 각 기능들에 대해 나누고 구조화하여 코드를 작성할 수 있게 됩니다. 이로 인해 재사용 성을 보장하면서 코드를 작성하게 됩니다.디
두 번째, 설계 수정 시간의 단축
이건 그림에서 봤다시피 설계하고 개발하고 테스트 하다가 다시 설계 가는 것보다 설계 - 테스트 - 설계 - 테스트 하는게 더욱 빠르고, 설계를 만족시키면서 구조와 기능의 정의를 명확하게 작성하게 되므로 설계의 문제를 바로 찾을 수 있게 됩니다.
실제로 현업에서 그냥 작업했을 때, 클래스와 인터페이스 등등을 자주 수정하게 되는데, 이러한 내용을 미리 테스트하게 됨으로서 사이드 이펙트를 최소화하여 작업할 수 있게 됩니다.
세 번째, 디버깅 시간의 단축
단위 테스트 기반의 테스트 코드를 작성하기 때문에 나중에 문제 발생 시 각각의 모듈 별 테스트를 진행할 수 있고 해보면 쉽게 문제가 발생하는 곳을 찾아낼 수 있게 됩니다. 그렇지 않다면, 각 문제발생이 의심되는 모든 코드를 읽어 통합 테스트하게 될 것 이고, 문제가 발생하는 부분에 대해 쉽게 찾긴 어려울 것입니다. 하지만 TDD 로 인해 각각의 단위 테스틀 진행한다면 영역을 분할해 쉽게 찾을 수 있을 겁니다.
네 번째, 테스트 문서의 대체 기능
테스트 리스트를 만들고 테스트가 잘 되었는지, 이슈는 없었는지 정리하는 문서를 정리하는 경우가 생긴다. 이에 대해 TDD 를 통해 테스팅을 자동화 시키고 보다 정확한 테스트 근거를 산출할 수 있게 된다.
추가 구현의 용이함
개발이 완료된 소프트웨어에 어떤 기능을 추가할 때 가장 우려되는 점은 해당 기능이 기존 코드들에 어떤 영향을 미칠지 모른다는 점이다. 따라서 단순한 기능이라도 추가 된 후에는 모든 기능들을 처음부터 테스트 해야한다. 하지만 TDD의 경우 자동화된 유닛 테스팅을 전재하므로 이러한 테스트 기간 역시 획기적으로 단축시킬 수 있다.
TDD의 단점
예상했겠지만 가장 큰 단점은 바로 생산성의 저하다. 단순한 어플리케이션을 개발하는 경우 경험에 의해 어떤 예외상황이 발생할지 눈에 뻔히 보이는 경우가 많다. 특히 이러한 단발성 개발은 개발 기간이 타이트하게 잡히는 경우가 많은데, 이럴 때 TDD를 적용해 뻔한 테스트 코드를 작성하고 그에 통과하기 위한 코드를 작성한다면 마치 답을 알고 푸는 문제집처럼 따분하고 비효율 적일 것이다.
본 포스팅에 참고한 박경훈 님의 글에 의하면 아래와 같은 경우도 있다고 한다.
TDD로 프로젝트를 진행하면서 어려운 예외가 생길 수 있는데 그것 때문에 고민하는 순간이 찾아오게 된다. 원칙을 깰 수는 없고 꼼수가 있기는 한데 그 꼼수를 위해서 구조를 바꾸자니 이건 아무래도 아닌 것 같고, 테스트는 말 그대로 테스트일 뿐 실제 코드가 더 중요한 상황인데도 불구하고 테스트 원칙 때문에 쉽게 넘어가지 못하는 그런 경우다.
이 TDD 의 장/단점을 다 살펴봤을 때, 득인가 실인가는 회사가 판단할 부분이라고 생각된다.
적극적으로 이야기를 해볼 수 있으나 회사에서 받아들여주지 않을 수 있지 않는가?? 대부분의 회사는 너무나도 일정이 바쁘기에 TDD를 바로 적용하긴 어렵곘지만, 조금씩 본인이 적용하고 남들에게 권유해나간다면 받아들여지지 않을까 라고 난 생각한다.
P.S. 할 수 있나..
출처블로그/글
- https://manorgass.tistory.com/63
- m.blog.naver.com/suresofttech/221569611618
- https://soulpark.wordpress.com/2012/09/12/test-driven-development/
- 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