직접 만든 앱이 마음에 듭니다. 하지만 한 가지 문제가 있죠. 바로 테스트 코드가 하나도 없다는 것입니다. 원래는 TDD(Test-Driven Development, 테스트 주도 개발)로 작성하고 싶었지만 어디서부터 시작해야 할지 몰라 결국 지금 모습이 되어버렸습니다. 그렇다면 이제 어떻게 해야 할까요? 테스트 없는 앱에서 어떻게 TDD를 적용한 개발로 나아갈 수 있을까요?
1단계: 이미 있는 코드부터 테스트하기
테스트 없이 작성된 코드가 많더라도, 지금이라도 기존 코드에 대한 테스트를 작성할 수 있습니다. 먼저 이미 작성한 코드를 테스트하면서 내 코드가 의도한 대로 동작하는지 확인하세요.
물론 이것은 엄밀히 말해 TDD가 아닙니다. 하지만 기존 코드에 대한 테스트 작성은 TDD를 배우는 데 큰 도움이 됩니다.
-
엣지 케이스와 오류 상황을 고민하는 습관이 생깁니다.
모든 가능한 입력값을 일일이 테스트하려면 몇 년이 걸리겠죠. 그래서 테스트를 작성하려면 코드가 가장 깨질 가능성이 높은 지점을 생각해야 합니다. 예를 들어 문자열을 받는 메서드가 있다면, 심볼(symbol)을 넘기면 어떻게 될까요?
nil을 넘기면요? 숫자를 나누는 함수를 테스트한다면 반드시 0으로 나누는 경우를 확인해야 합니다. 반면 1과 2로 각각 테스트할 필요까지는 없겠죠.충분히 테스트를 작성하다 보면 어느 부분에서 코드가 깨지기 쉬운지 예측할 수 있게 됩니다. 그리고 본격적으로 TDD를 시작할 때 이 능력을 활용하면, 엣지 케이스를 확실히 다루는 견고한 테스트를 작성할 수 있습니다.
-
구조화된 테스트를 작성하는 연습이 됩니다.
코드를 먼저 작성하고 테스트를 나중에 붙이는 방식에서는 다양한 테스트 구조 패턴을 시도해 볼 수 있습니다. 테스트 대상 코드가 이미 존재하므로 테스트 자체와 그 작성 방식에만 집중할 수 있기 때문입니다. 좋은 패턴 몇 가지를 익히고 나면, 나중에 의지할 코드 없이 TDD로 개발할 때에도 더 나은 테스트를 작성하게 됩니다.
-
코드를 테스트하기 어렵게 만드는 요인을 발견하게 됩니다.
테스트를 많이 작성하다 보면 시스템에서 어떤 부분이 가장 테스트하기 어려운지 감각이 생깁니다. 그런 영역을 발견하면 리팩토링이 필요한 곳으로 표시해 두세요. 더 좋은 점은, 처음부터 테스트하기 쉬운 코드를 작성하는 습관이 생긴다는 것입니다.
테스트하기 쉬운 코드가 어떤 모습인지 알게 되면, 그 지식을 바탕으로 TDD로 테스트 친화적인 API를 설계할 수 있습니다. 이는 앱 개발 속도를 높이는 데도 도움이 됩니다.
2단계: 회귀 테스트로 TDD에 익숙해지기
나중에 테스트를 붙이는 방식(test-after)은 TDD를 배우는 데 필요한 실력을 쌓는 데 유용합니다. 하지만 결국에는 앱의 일부라도 직접 TDD로 개발하고 싶어질 것입니다. 이때 기존 코드를 활용하면서 TDD에 자연스럽게 적응하는 간단한 방법이 있습니다. 바로 회귀 테스트(regression test)를 작성하는 것입니다.
회귀 테스트는 이미 수정한 버그가 다시 발생하지 않도록 지켜줍니다. 아이디어는 아주 단순합니다. 버그 소식을 들으면 브라우저에서 클릭하며 재현하는 대신, 다음 순서를 따르세요.
- 버그를 재현하는 실패하는 테스트를 작성합니다.
- 테스트를 실행해서 실패하는지 확인합니다(버그가 여전히 존재하기 때문입니다).
- 가장 단순한 방법으로 버그를 수정합니다.
- 테스트를 실행해서 통과하는지 확인합니다.
- 필요하다면 수정한 코드를 리팩토링합니다.
이 과정은 새로운 시스템을 처음부터 끝까지 TDD로 만드는 것보다 훨씬 쉽습니다. 이미 존재하는 코드에 변경 사항을 테스트 주도로 적용하는 것이기 때문입니다. 이 과정을 반복하면 TDD의 핵심 사이클인 "레드-그린-리팩터(Red, Green, Refactor)" 습관이 자연스럽게 몸에 배게 됩니다. 여기까지 오면, 테스트가 전혀 없는 상태에서 바로 TDD로 뛰어드는 것보다 훨씬 짧은 거리만 남습니다.
테스트 없는 상태에서 TDD까지
테스트 없는 앱이 출발점으로 나쁜 것은 아닙니다. 기존 코드를 테스트하다 보면 좋은 TDD 테스트를 작성하는 데 필요한 것들을 대부분 익히게 됩니다. 또한 처음에는 테스트를 나중에 붙이는 방식이 TDD보다 쉽습니다. 아직 설계 방법을 모르는 API를 상상하며 테스트를 먼저 작성할 필요가 없기 때문입니다. 그리고 TDD를 도입하기로 결심했다면, 회귀 테스트를 통해 무리 없이 전환할 수 있습니다.
따라서 지금 구상 중인 시스템을 어떻게 TDD로 개발해야 할지 모르겠다면, 그냥 테스트 작성을 계속하세요. 코드를 먼저 작성해야 한다 해도 말입니다. 그 경험이 쌓이면 어느새 TDD 개발자가 되어 있을 것입니다.