인수 테스트로 더 나은 TDD를
테스트 주도 개발(Test Driven Development, TDD)과 테스트는 내가 굉장히 관심을 가지는 주제들이지만, 처음에는 그렇게 매력적으로 다가오지 않았다. 동료들과 함께 스터디를 진행하고 관련 서적도 읽어보았지만, 그것이 깊은 이해나 필요성을 느끼는 데에 큰 도움이 되지는 않았다.
TDD에 대한 흥미는 완성도 높은 테스트 환경을 접한 후부터 서서히 생겨났다. 새롭게 합류한 팀의 코드 저장소에는 많은 테스트 코드가 있었고, 그중에서는 TDD를 활용한 개발의 흔적들도 보였다. 다양한 테스트 코드들은 매우 인상적이었다. 아무도 나에게 강제로 시키지는 않았지만 나도 이러한 방법으로 개발을 하고 싶다는 마음이 생겼다. 잘 구축된 테스트 전략이 있는 환경에서는 테스트 학습과 적용이 그다지 어렵지 않았다. 기능을 구현하기에 앞서, 유사한 기능에 대한 테스트 코드가 이미 작성되어 있는지 먼저 확인한 후, 그것들을 참고해서 테스트 코드를 작성하였다. 그러고 나서 개발을 이어갔다. 비록 처음에는 이 과정이 번거로웠지만, 코드를 작성하기 전에 구현하려는 코드의 목적을 명확하게 이해하게 되었다. 그 결과 개발이 완료되었을 때에는 완벽한 테스트 코드가 함께 생성되었다. 페어 프로그래밍을 통해 개발을 진행하였기 때문에, 처음에는 낯설었던 이 개발 프로세스를 지속적으로 유지할 수 있었다.
나는 새로운 것에 흥미를 느끼며 몰입을 잘하는 편이지만, 그 몰입은 시간이 지나면서 자연스럽게 만나게 되는 막막함과 답답함으로 인해 깨지곤 한다, TDD도 마찬가지였다. 사람들은 종종 "TDD는 참 좋지만 실무에서는 불가능하다"라고 이야기한다. 역시 괜히 나오는 이야기가 아니었다. 당시 내가 겪었던 여러 가지 어려움 중 몇 가지를 이야기해 보자면, 우선 TDD 사이클을 한 번 완료한 후 어떤 대상으로 다음 사이클을 진행할지 결정하는 것이 어려웠다. 많은 테스트 코드가 있었지만, TDD를 하는 데 있어 어떤 순서로 개발을 해 나갈지, 어떤 프로세스를 따를지에 대한 도움을 받기는 어려웠다. 테스트를 먼저 작성하지 않고는 절대로 프로덕션 코드를 작성해서는 안 된다는 규칙이 다음 코드 작업 대상을 결정하는 데 있어 힘들게 만들었던 것 같다. 두 번째 어려웠던 점은 전체 기능이 제대로 동작하는지 파악하는 것이었다. TDD를 통해 기능 구현을 끝낸 뒤 부분적으로는 잘 동작하는 것을 확인할 수 있었다. 하지만, 전체 기능이 제대로 동작하는지 확인하는 것은 쉽지 않았다. TDD 과정에서는 전체보다는 부분에 집중해서 작업을 했기 때문에, 작업을 마무리하더라도 확신을 갖기가 어려웠다. 이런 불안감을 해소하려면 로컬이나 개발 환경에 빌드 후 배포하여 확인하는 과정이 필요했는데, 이 과정은 상당한 시간을 소모했다.
팀의 코드 저장소에는 다양한 테스트 코드가 작성되어 있었다. 그중에는 인수 테스트(Acceptance Test)라는 생소한 테스트 코드도 있었다. 인수 테스트는 전 구간에 대한 테스트로, 부분적인 코드나 기능만을 검증하는 것이 아니라 특정 기능에 대한 전체적인 플로우를 검증한다. 사실 이전에 나의 스승님이자 팀장님이셨던 포비가 TDD 할 때 어려움을 겪게 된다면 인수 테스트에 대해 알아보라고 이야기해 준 적이 있었는데, 잊고 지내다가 실제로 어려움을 겪고 나서야 인수 테스트와 ATDD(Acceptance Test Driven Development)에 대해 알아보고 싶은 마음이 생겼다. 그리고 진지하게 공부하기 시작했다.
인수 테스트가 TDD의 모든 아쉬운 점을 해결해주지는 못했지만, 몇 가지 상황에서 아주 큰 도움을 주었다. 인수 테스트를 먼저 작성하고 그다음에 기능 구현을 진행하다 보니, 작업의 목표가 명확해졌다. '작업이 끝났을까?'라는 생각을 가지고 조심스럽게 빌드와 배포를 시도하는 대신, 인수 테스트를 수행했다. 미흡한 부분이 있다면 에러 로그를 통해 바로 알려주었기 때문에 배포하여 확인하는 것보다 시간을 절약할 수 있었다. 이 외에도 인수 테스트는 개발을 진행할 때 어떤 방향으로 개발을 해야 할지를 알려주었다. 처음 접하는 도메인이라 개발 과정이 매끄럽지 않았던 적이 많았다. 그래서 도메인 설계를 먼저 하기보다는 시나리오를 먼저 고려하고 이를 기반으로 인수 테스트를 작성했다. 그 결과 기능 요구사항에 대한 이해도가 높아져 개발을 시작할 때 더욱 명확한 이해를 바탕으로 설계를 할 수 있었다. 불완전한 도메인 설계를 바탕으로 TDD를 시작하는 것보다는, 상대적으로 완전한 API 설계와 시나리오 흐름을 먼저 고려하며 개발을 시작하니, 자신감도 생겼다. 어느 순간부터 나는 인수 테스트의 신봉자가 되었다.
