자동화된 테스트를 작성하는 것은 높은 품질의 프로그램을 만드는데 중요한 요소입니다. 그래서 프로그램을 어느 정도 짤 줄 알게 된 프로그래머는, 자연스럽게 자동화된 테스트를 짜는 법을 배우려 하게 되지요. 그런데 그렇게 “자동화 테스트”라고 검색을 하면, 어떤 이유에서인지 “테스트주도개발”이라는 키워드들이 많이 보이게 됩니다. 그리고 관련 글들을 몇 번 읽다 보면, “테스트라는 것은 원래 프로그램을 짜기 전에 작성하는 것이 정석이구나”라는 생각을 하게 되지요.
어떤 의미에선 맞습니다. 프로그램을 짜기 전에 자동화된 테스트를 짤 수 있다면 가장 좋지요. 그런데 테스트주도개발의 방식은 테스트 작성을 입문하는데에는 최적의 방법이 아닐 수도 있습니다. 자동화 테스트도 결국에 하나의 프로그램이고 도구입니다. 어떤 API들이 있고, 어떻게 행동하는지를 먼저 이해해야 제대로 된 테스트를 작성 할 수 있습니다. 테스트 프레임워크의 사용법을 제대로 이해하지 못한 상태에서 무작정 작성한 테스트는, 당연히 처음 돌릴 때 실패하겠지만, 제대로 구현된 구현체에 대해서도 실패하기 쉽습니다. 이런 경험이 몇 번 반복되고 나면, “테스트 작성은 어려운 것”이구나 라면서 테스트를 포기하게 되는 경우도 생길 수있다고 봅니다.
자동화 테스트만 테스트가 아니에요
저는 테스트를 먼저 작성해야 한다는 말에는 동의합니다. 그런데 특히 입문자의 경우에는, 그 테스트가 반드시 “자동화된 테스트”일 필요는 없다고 생각합니다. 저는 “어떤 형태로든” 테스트가 먼저 작성되는 것이 가장 중요하다고 생각해요. 그러니까, 그냥 종이에 연필로 체크리스트의 형태로라도, 테스트케이스를 먼저 만들어보세요. Happy Path는 무엇인지, Edge Case는 무엇인지를 미리 적어보는 겁니다. 종이에 적어둔 테스트케이스는 나중에 훌륭한 커밋 메시지, 또는 좋은 PR 제목이 될 수도 있습니다. PR 제목이 테스트 케이스의 형식이라면, 리뷰하기 정말 편할 것 같지 않나요?가장 중요한 것은 “내가 무엇을 만드는지” 제대로 알고 코드를 짜는 일입니다. 자동화된 테스트를 미리 작성하는 것은 이 상황을 만들기 위한 가장 좋은 수단이지, 유일한 수단은 아닙니다.
이런 방식의 테스트 작성은 아무런 사전 지식이 필요하지 않고 당장 적용할 수 있다는 점에서 가장 쉽게 테스트주도개발을 연습 할 수 있는 방법입니다. 더 나아가, 이렇게 문서로 작성된 테스트는 자동화된 테스트와는 또 다른 여러 장점이 있습니다. 바로 조직의 여러 구성원들로부터 피드백을 받기 좋다는 점이죠. 테크스펙을 쓰는 단계에서 이 테스트들이 작성된다면, 리뷰어들은 코드를 리뷰전에 내가 어떤 엣지케이스를 놓쳤는지 알려 줄 수 있게 됩니다. 또 QA를 담당하는 인력에게도 내가 작성한 테스트들을 공유하면 그 분들의 작업 이해도나 작업 속도에 큰 기여를 할 수 있게 되죠.
일단 이렇게 테스트를 먼저 작성하는 습관을 들인다면, 자동화된 테스트를 작성하는 일도 훨씬 쉽게 익히게 될 수 있다고 봅니다. 테스트 작성이 익숙한 상태에서는 자동화 테스트 프레임워크가 “뭘 어떻게 하는 건지 알 수 없는” 미지의 도구가 아니라, “내가 수동으로 하던 테스트를 대신 해주는” 편리한 도구로 인식 될 수 있을테니까요.
테스트주도 개발을 하기 위해, 비싼 동영상 강의를 수료하기를 기다릴 필요는 없습니다. 본질적인 의미에서의 테스트주도 개발은 누구라도, 지금 당장 시작 할 수 있습니다.