TDD - Test Driven Development
😮
본 글은 프로그래밍 관련 개념을 개인적인 공부 차원에서 ‘다섯살 짜리 아이도 이해할 수 있는 수준’으로 설명하는 것을 목표로 작성한 글입니다!
훨씬 더 자세하고 전문적으로 설명한 글들은 본 게시물 하단의 참조 링크를 통해 확인하실 수 있습니다.
쉽게 설명하기 위한 예시와 비유, 함축적 표현 등이 부정확하게 전달될 수도 있으니 유의해주시고 개선해야할 점이 보인다면 댓글로 알려주세요.
***
TDD
Test Driven Development의 약자로 한국어로는 “테스트 주도 개발”이라고 부릅니다. 기술적인 개념이라기 보다는 ‘어떻게 하면 개발을 효율적으로 할 수 있을까?’하고 고민한 개발 방법 이론에 가깝습니다. (물론 TDD를 하려면 ‘테스트 코드’라는 기술적인 부분이 생기지만요!)
공부를 할 때에도 바로 책의 첫 장부터 쭉 읽는 방법이 있는가하면, 수업을 들으면서 진도에 맞춰 예습, 복습을 해서 배운 내용을 더 확실하게 이해하고 기억하는 방법도 있고 깊게 가면 ‘뽀모도로 공부법’ 같은 것들도 있듯이 TDD 역시 개발을 하는 다양한 방법 중 하나일 뿐입니다.
TDD가 제시하는 개발 방법은 계속해서 내가 만든 프로그램을 테스트하면서 코드를 작성하는 것입니다.
‘그건 너무 당연한 거 아닌가요?’ 네. 코드를 작성했다면 그게 정상적으로 실행되는지 테스트해보는 것은 너무 당연한 과정일 수도 있습니다. 대다수의 회사들이 QA팀을 두고 테스트만 전문적으로 실행하기도 하니까요.
다만 TDD의 차이점은 만들 기능을 테스트하는 테스트 코드를 먼저 작성해 놓고 거기에 맞춰서 기능을 개발한다는 것입니다. 말그대로 테스트가 개발을 주도하는 것입니다.
테스트
테스트는 학교에서 치르는 시험과 비슷합니다.
학교에서는 가르친 내용을 학생이 잘 배웠는지 확인해야하는데 단순하게 ‘넌 뭘 배웠니?’라고 물어보면 필요한 내용을 정확하게 배웠는지 확인하기도 어렵고 오늘은 배워서 잘 대답했던 내용을 내일은 까먹고 대답하지 못하더라도 일일히 확인하기가 어렵습니다. 그래서 학교는 시험을 만들어서 중간고사, 기말고사 같이 주기적으로 배운 내용들을 확인하고 시험지를 통해 학생들이 정확히 어떤 내용들을 알고 있어야하는지 구체적으로 보여줍니다.
TDD에서의 테스트도 같은 역할을 합니다.
우리가 만드려는 프로그램이 입력한 내용에 따라 정확히 어떤 결과값들을 출력해야하는지 확인할 수 있는 테스트 코드를 먼저 작성하고 거기에 맞춰서 개발을 진행하여 작성한 코드가 엉뚱한 결과물을 만들어내지 않도록 확인하면서 개발을 진행하는 것입니다. 이렇게 하면 새로운 기능이 추가될 때마다 사이드이펙트는 없는지 모든 기능을 하나하나 확인할 필요없이 우리가 만든 프로그램에게 시험지 한 장만 주고 모든 문제를 잘 푸는지 확인만 하면 됩니다.
그리고 테스트는 확인하고자 하는 기능의 범위나 목표에 따라 가장 보편적으로 이루어지는 단위(Unit) 테스트부터 Function, Integration, Component, Smoke, E2E, Performance 테스트 등 다양하게 존재합니다.
순서는 테스트를 위한 문제를 내고, 문제를 풀 수 있는 최소한의 코드를 작성하고, 작성한 코드가 문제를 잘 풀면 그 다음에 코드를 개선시키는 과정으로 진행합니다. 이 순서를 각각 Red, Green, Blue 단계라고도 합니다.
장점
TDD의 장점은 빠르게 프로그램의 문제점을 파악하고 개선시키면서 프로그램을 더욱 튼튼하게 만들어갈 수 있다는 것입니다. 우리의 학생이 무엇을 모르고 있고, 어떤 과목에 약한지가 채점한 시험지에 모두 보이기 때문이죠.
작성해 놓은 테스트코드를 잘 유지하고 관리하기만 한다면 테스트 실행만으로 문제가 어디에서 발생하는지 확인하기가 쉬워지기 때문에 디버깅에 들어가는 시간이 줄어들고, 반복해서 문제가 생기는 부분들을 확인해가면서 프로그램을 보완한다면 문제가 터지고 나서야 급하게 해당 부분만 겨우 고치는 방식보다 훨씬 더 안정적인 결과물을 만들 수 있을 겁니다.
게다가 개발자의 입장에서는 테스트 코드를 작성하면서 미리 어떤 기능을 만들 것인지 정리하고, 예외사항들을 생각해 볼 수 있기 때문에 설계 시간을 줄일 수도 있습니다.
단점
TDD의 단점은 개발 속도가 느려질 수 있다는 것입니다.
‘엥? TDD를 하면 개발 시간이 줄어든다고 하지 않았나요?’ 장기적으로 봤을 때는 디버깅과 코드 개선에 들어가는 시간이 줄어들지만 바로 내일까지 어떤 기능을 만들어내야 하는 상황에서는 테스트 코드를 작성하는 과정이 추가되기 때문에 상대적으로 할 일이 더 많아지고 개발 시간이 더 길어질 수 있습니다.
모든 ‘방법론’이 그러하듯 이상적인 상황에서는 기대하는 장점들을 얻을 수 있지만 그렇지 못한 상황에서는 도입하는데 시행착오를 겪고 오히려 단점만 크게 부각될 수 있습니다.
TDD를 도입하기 위해서 테스트 코드 작성 방법에 대해서도 배우고 고민해야하고 회사라면 개인뿐만 아니라 팀원들이 다함께 노력해야 하는데 빠르게 성과를 내는 것이 중요한 환경이라면 오히려 원하는 목표에 도달하기까지 걸리는 시간을 늦출 수도 있게 되는 것이죠.
결론
최근 많이 유행하면서 실제로 TDD를 도입한 조직들도 많고 이론적으로는 좋은 방법인 것 같아 공부를 해봤습니다. 현재 일하고 있는 팀에서도 TDD를 도입하려다가 실패한 케이스가 있어서 당장 적용을 하기는 어려울 것 같지만 우선 장점이 확실하고, 많은 개발조직이 워터폴에서 애자일로 넘어가고 있듯 TDD 역시 한 순간의 유행이 아닌 하나의 문화로 계속해서 자리를 잡아갈 것으로 보여 개인적으로라도 실행을 해보면 좋을 것 같습니다.
댓글남기기