필자는 지금까지 테스트 코드를 한번도 작성해 본 적이 없는 테린이였지만 (진행중) 최근 입사한 회사에서는 BDD를 적극적으로 적용하고 있기 때문에 신입 과제를 수행하며 테스트 코드에 대한 느낀 점과 함께 테스트 코드를 바라보는 다양한 관점에 대해 개인적인 생각을 짧게 적어보려 한다.
TDD
TDD는 "Test Driven Development"의 약자로서, 말 그대로 테스트 주도 개발이다.
TDD란 말이 나온지는 굉장히 오래되었다. 필자도 이전부터 TDD에 대한 이야기를 자주 접했지만 많은 회사와 개발자에게 공통적으로 "TDD가 좋은거 알겠는데 생산성이 너무 떨어져" 또는 "굳이 도입할 필요성을 못 느끼겠어" 라는 말을 자주 들을 수 있었다.
특히 스타트업의 경우 제한된 리소스로 빠른 성장을 가져가야 하기 때문에 테스트 코드까지 작성하고, 관리할 여유가 없는 것이 대표적인 이유였다.
필자 역시 테스트 코드를 경험해보기 전에는 이런 생각을 가진 사람 중 한명이였다.
실제로 테스트 코드가 가져다 주는 장점은 이미 많이 알려져있고, 누구도 동의하지 않을 수 없는 단계에 와있다고 생각한다.
하지만 여전히 테스트 코드에 대한 부정적인 견해와 환경적인 한계로 인해 도입을 망설이는 사람들이 많다.
필자가 테스트 코드란 여전히 어렵고, 부담스러우며, 테스트 코드에 대한 코스트가 너무 크다고만 생각하고 있을 때 현 회사의 파트장님께서 이러한 말을 해주셨다. "테스트 코드가 가져다 주는 장점들을 알고 있지만 다른 단점들을 얘기하며 여전히 시도하려 하지 않고, 도입을 꺼리는 것은 테스트 주도 개발을 해보지 않았거나 제대로 운영해보지 못했기 때문이다."
아직 위의 말을 완전히 이해했다고는 할 수 없다. 그 이유는 필자가 여전히 테스트 코드에 대한 부정적인 견해를 가져서가 아니라 아직 제대로 경험해보지 못했고, 진정한 테스트 주도 개발을 해보지 못했기 때문이다.
하지만 위의 말을 통해 진정한 테스트 주도 개발을 경험해 볼 수 있다는 기대가 생겼기 때문에 한 번 도전해보고 싶다는 생각이 들었고, 실제로 지금은 테스트 코드를 작성하는 것이 마냥 힘들지만은 않다. (5일차..)
BDD, 그리고 TDD와의 작지만 큰 차이
BDD는 "Behaviour Driven Development"다.
Test와 Behaviour(이하 Behavior) 의 차이가 무엇인지 처음엔 어려웠지만 지금은 그저 단순히 테스트 코드를 작성하는 관점과 워크플로우의 차이지 큰 차이가 있는 것은 아니라고 생각하고 있다. 또한 TDD는 TDD만의 의미가 있지만 TDD와 BDD 모두 결국 Test Driven Development 이기 때문에 TDD가 할 수 있는 것과 BDD가 할 수 있는 것을 나누는 것은 크게 의미가 있다고 생각하지 않는다.
하지만 그렇다고 해서 TDD와 BDD가 정말로 차이가 없는 것은 아니다.
먼저 TDD는 코드 자체에 집중한 테스트 코드를 작성하기 때문에 BDD에서 말하는 Side Effect를 포함하고 있는 경우가 많고, 코드에 집중된 테스트 코드는 결국 이것만으로 비지니스 요구 사항에 따른 로직을 파악하기 어려워진다. 또한 이러한 점은 결국 비지니스 요구 사항이 변경되었을 때 기존 비지니스 로직과 테스트 코드를 수정하는데 있어 비교적 BDD 보다 큰 코스트를 가져다 주는 단점이 된다.
BDD는 TDD를 포함하고 있는 개념이기 때문에 테스트 주도 개발 자체로만 봤을 때는 두 개를 나누는 것이 큰 의미가 없지만 코드 자체에 집중된 테스트 코드로 인해 발생하는 TDD의 단점을 BDD에서는 Side Effect를 제외한 Behavior 기반으로 비지니스 요구 사항에 집중한 테스트 코드를 작성하기 때문에 좀 더 의도와 목적을 구체적으로 한 테스트 코드 작성 방법이라고 할 수 있다.
BDD는 TDD를 포함하고 있고, 실제 비지니스 로직에 대한 Behavior들을 통해 테스트 코드를 작성한다고 생각하면 좋을 것 같다. (물론 BDD는 더 이론적으로 팀 간의 공유된 "Artifacts"를 기반으로 비개발자와도 대화 가능한 자연어에 가까운 테스트 코드라고 할 수 있으며, Given, Expect(Then)과 같은 비지니스 요구 사항에 대한 시나리오를 바탕으로 테스트 코드를 작성한다.)
그리고 BDD를 이해하는 순간 (깊은 이해를 의미하는 것이 아니다. 단순히 행동을 기반으로 테스트 코드를 작성하는 방법론이라고만 이해해도 충분하다.) 자유롭고, 추상적이던 TDD가 구체적으로 느껴진다.
예시로 MVC 기반의 컨트롤러와 서비스가 있다고 생각해보자.
서비스에는 비지니스 요구 사항에 대한 비지니스 로직들이 들어있을 것이다.
크게 보면 BDD에서 의미하는 Behavior이 비지니스 요구 사항들이라고 생각해도 좋다.
그리고 BDD를 실천하는 순간 비지니스 요구 사항에 대한 로직들을 코드로 먼저 구현하지 않고, 테스트 코드로 먼저 작성한 후 테스트 코드의 안정성을 기반으로 서비스에 들어갈 비지니스 로직들을 작성할 수 있어진다. (물론 TDD도 이것이 가능하지만 가장 큰 차이는 테스트 코드의 의도를 명확히 어디에 둘 것인지 이다.)
이것은 코드를 먼저 구현하고, 테스트하는 과정을 거치는 것이 아닌 테스트 코드를 먼저 작성하고, 코드를 검증해나가며 작성할 수 있는 장점을 가져오며, 많은 사람들이 테스트 주도 개발의 단점이라고 부각시키는 생산성 저하에 대한 반박이 될 수 있다.
하지만 위의 문장을 본 후 결국은 테스트 코드라는 하나의 태스크가 추가된 것인데 테스트 코드의 안정성을 기반으로 서비스 코드를 작성하는 것이 개발의 안정성을 가져다 줄지는 몰라도 어떻게 생산성에 영향을 주지 않을 수 있냐는 생각을 할 수 있다.
이러한 생각은 당연하다. 하나의 일만 할 수 있는데 두 개의 일을 하는 것은 당연히 시간이 더 오래 걸릴 수 밖에 없다.
하지만 생각해보면 실제로 바로 코드를 작성한다고 해서 테스트가 필요하지 않은 것이 아니다. 단순한 API를 구현하더라도 Postman 등의 HTTP 클라이언트 도구 또는 콘솔 등을 통해 테스트와 개발을 항상 병행된다.
그리고 이것은 단계적인 검증을 위한 테스트가 아닌 산발적인 테스트가 될 수 밖에 없고, 재사용이 불가능한 테스트가 된다.
결국 테스트 코드라는 한 단계의 태스트가 개발에 추가된 것이지만 테스트 코드를 잘 작성하면 내 코드에 대한 안정성을 가져갈 수 있고, 이것을 바탕으로 빠르게 비지니스 로직을 구현할 수 있으며, 재사용이 가능한 테스트가 가능해진다. 또한 추가 요구 사항에 대한 추가 개발과 리팩토링도 안정성 있게 진행 할 수 있다.
하지만 어디까지나 BDD나 TDD 같은 방법론들은 하나의 매커니즘이 될 수 있는 것이지 정답은 아니기 때문에 예찬하는 것은 옳지 않다. 따라서 실제로 테스트 주도 개발을 도입하려 할 때 테스트 코드에 대한 커버리지를 확실히 정한 후 코스트를 따지는 것이 테스트 주도 개발을 개인 또는 팀 내에 효율적으로 도입할 수 있는 방법이 될 것이다.
마치며
최근 테스트 코드를 작성하며, TDD와 BDD에 대한 의문들이 하나씩 풀리는 것 같다. 그리고 이것이 곧 TDD와 BDD를 이해하는 과정이라고 생각하기 때문에 머지 않아 진정한 테스트 주도 개발을 해 나갈 수 있다는 기대감이 생겼다.
사실 필자가 테스트 코드를 빠르게 이해했고, 나에게 잘 맞아서 이런 생각을 하게 된 것은 아니다.
항상 타인의 글에는 개개인의 주관적인 생각과 경험이 녹아있기 때문에 인터넷을 통해 공부를 할 수록 실타래가 엉키는 느낌이였지만 현 회사의 파트장님께서 본인의 경험과 생각을 아낌없이 공유해주신 것을 계기로 짧은 시간 동안 테스트 주도 개발을 시작하는데 충분한 바탕을 다질 수 있었다. 그리고 이것은 TDD와 BDD에 대해 더 깊이 고민할 수 있는 계기를 갖게 해주었고, 그러한 고민을 기록하고, 공유하기 위해 해당 글을 작성하게 되었다.
BDD는 경험해보니 정말 재밌다.
TDD는 개발자 개인에 따라 작성하는 방식이나 운영하는 방식 등에서 많은 차이가 있을 수 밖에 없기 때문에 실제로 타인이 코드를 보기 어려운 경우가 많다고 생각한다. 그리고 이것이 TDD가 어려운 점이고, 허들이 되는 부분이다. 하지만 BDD는 "Behavior"이라는 구체적인 관점 또는 단위가 명확하기 때문에 TDD가 어렵고, 추상적이라고 생각하는 사람들은 BDD를 경험해보길 적극 권장한다.
그리고 앞으로는 실제 BDD를 개발에 적용하며, 느끼는 점들을 코드와 함께 글로 기록하려고 한다. 또한 BDD에 대해서도 많은 사람들이 바라보는 관점이 다르고, 특히 정말 많은 사람들이 여전히 "Integration Test"와 "Unit Test"를 혼용하며 개발하고 있기 때문에 해당 주제에 대해서도 개인적인 생각들을 차례대로 글을 작성할 예정이다.
안녕하세요. 평범한 개발자 yorr입니다.
포스팅을 읽고 궁금한 점 또는 문의가 있으신 분은 메일 또는 댓글을 남겨주세요.
Mail: twysg@likelion.org
Github: https://github.com/sangyeol-kim