훌륭한 개발자라면 코드에 테스트를 작성해야 한다는 것을 압니다. 하지만 현실에서는 테스트가 자주 생략되거나, 대충 때우거나, 아예 시작조차 되지 않곤 합니다. 많은 개발자들이 반복적으로 빠지는 전형적인 함정들이 있는데, 이 함정들은 매번 테스트를 작성하려는 동기를 꺾어버립니다. 오늘은 그 함정 다섯 가지와 극복 방법을 살펴보겠습니다.
1. RSpec? Cucumber? Capybara? Minitest? 무엇을 써야 할까?
새 프로젝트를 시작할 때 '가장 좋은 도구'를 고르느라 지나치게 많은 시간을 소모하기 쉽습니다. 사실 이런 미루기 행동은 어디서부터 시작해야 할지 모른다는 사실을 감추는 것일 뿐입니다. 그리고 도구를 정하기 전까지는 실제로 생산적이지 않으면서도 생산적인 느낌만 받을 수 있죠.
대신 가장 잘 아는 스택을 선택하세요. 특별히 익숙한 테스트 스택이 없다면 기본값을 따르세요. Rails가 기본으로 제공하는 것부터 시작하면 됩니다. 나중에 언제든 추가할 수 있습니다. 새로운 도구를 시도하는 것 자체는 잘못이 아니지만, 프로젝트와 작업 방식을 더 깊이 이해하게 된 후에 점진적으로 도입하는 것이 훨씬 바람직합니다.
2. 단위 테스트부터? 기능 테스트부터? 통합 테스트부터?
프로젝트를 시작할 때 어떤 기능이나 화면을 먼저 만들지 어렴풋이 알고 있을 것입니다. 여기가 바로 출발점입니다! 기능 목록에서 첫 번째 항목을 골라 실패하는 통합 테스트를 작성하세요. 그러면 어떤 컨트롤러와 라우트가 필요한지 알게 되고, 그 말은 곧 실패하는 기능 테스트를 작성해야 한다는 뜻입니다. 컨트롤러가 제 역할을 하려면 데이터와 로직이 필요하므로, 다음은 모델과 단위 테스트 차례입니다. 단위 테스트가 통과하면 기능 테스트도 통과하고, 통합 테스트까지 통과합니다. 이제 다음 기능으로 넘어가면 됩니다.
항상 다음 단계가 정의된 테스트 프로세스를 갖고 있으면 동기를 유지하기 훨씬 쉽습니다. 결정을 내릴 필요가 없다면 미루기가 스며들 여지도 자연히 줄어듭니다.
3. 네트워크 코드, CLI 유틸리티, rake 태스크는 어떻게 테스트하지?
가장 간단한 해법은 테스트하기 어려운 파일이나 클래스에서 가능한 한 많은 코드를 꺼내 테스트하기 쉬운 새로운 객체로 옮기는 것입니다. 그렇게 하면 테스트하기 어려운 부분은 새 객체를 생성하고 파라미터를 전달하는 역할만 남게 됩니다.
물론 원래 테스트하기 어려웠던 대상은 여전히 남아 있습니다. 하지만 이제 몇 줄 안 되는 코드일 것이고, stub이나 fake로 대체하기도 훨씬 수월합니다.
4. "프로젝트 거의 끝났으니 이제 테스트만 쓰면 돼!"
만나본 거의 모든 개발자는 코드를 배포하고 싶어 합니다. 테스트가 배포 직전의 마지막 관문이라면, 코드가 '아마도' 동작한다는 확신이 들 만큼 최소한의 테스트만 작성하게 됩니다. 이런 습관이 들면 테스트는 도움이 되는 것이 아니라 짜증나는 일로 보이기 시작하고, 테스트를 작성할 동기를 얻는 일은 더욱 어려워집니다.
TDD(테스트 주도 개발)가 좋은 점 중 하나는 테스트를 설계와 코딩 과정에 자연스럽게 섞어버린다는 것입니다. 그러면 테스트 작성 자체를 코딩의 일부로 여기게 되어 훨씬 재미있어지고, 테스트의 혜택도 훨씬 일찍 누릴 수 있습니다.
5. 내가 잘못하고 있는 건 아닐까?
Ruby 커뮤니티는 코드 품질, 단위 테스트, 객체 지향 설계 원칙을 강력하게 추구하는 것으로 유명합니다. 이것 자체는 훌륭한 일입니다! 하지만 불행히도 그 때문에 첫 시도부터 완벽한 코드에 100% 테스트 커버리지를 달성해야 한다는 엄청난 압박감을 느끼기 쉽습니다.
특히 오픈소스처럼 다른 사람들이 코드를 볼 것을 아는 프로젝트를 시작하기가 무척 어려워집니다. SOLID 원칙을 모두 따르지 않는 코드를 봤다면 사람들이 뭐라고 말할까요? 이런 압박감에 대처하는 데 도움이 된 몇 가지 교훈이 있습니다:
- 모든 훌륭한 개발자는 나중에 부끄러워하게 될 코드를 작성한 적이 있습니다.
- 출시된 좋은 코드는 출시되지 못한 완벽한 코드보다 무한히 낫습니다.
- 어떤 사람들은 그냥 까불거리며 당신의 코드를 놀릴 겁니다. 정말 기분 나쁜 일이고, 저 역시 그런 일로 몇 주 통째로 망친 적이 있습니다. 하지만 훌륭한 개발자는 비판하는 대신 당신을 돕고 싶어 합니다. 그리고 당신의 프로그래밍 영웅에게 그 코드를 보여준다면, 놀리는 대신 더 좋게 만들도록 도와줄 거라고 장담합니다.
당신은 어떤 함정을 발견했나요?
여기 소개한 함정 중에 해당되는 것이 있었나요? 그 함정에서 벗어나는 데 도움이 된 것은 무엇인가요? 그리고 여기서 언급하지 않은 다른 함정이 있다면 무엇인가요?
이 함정들 중 하나에서 자신을 발견했다면, 지금부터 그것에서 벗어나기 위해 어떤 행동을 실천할 계획인가요?