불운 김선생이라는 별명을 가진 친한 친구가 있다. 몇 개월 전 채용과정은 까다롭지만 소프트웨어 엔지니어 대우가 좋기로 소문난 회사로 이직을 했다. 그리고 얼마 전 통화 중에 나로서는 꽤 충격적인 이야기를 들을 수 있었다.
바로 위의 파트 리더가 단위 테스트를 만들어본 적이 없다는 것이다.... 게다가 필요성도 크게 느끼지 못한다고 한다. 물론 실력을 인정받고 있는 분이라고는 하지만 나에게는 신선한 충격이었다. 여전히..?
애자일 개발 방법론의 베스트 프렉티스 중에 하나인 테스트 주도 개발은 실제 업무에 적용하기 어려운 개발 방법 중에 하나라고 알려져 있다. 월화수목금금금과 야근, 특근에 치여 살던 개발자들에게는 중원의 고수만 사용할 수 있는 하지만 어디에서나 쓸 수 있는 은탄환 처럼 여겨지기도 했다. 그 때문일까? 소프트웨어 엔지니어가 당연히 만들어야 할 단위 테스트 조차 사람들에게는 멀게 느껴지는 듯하다.
우리 주변에는 개발자를 갈아 넣어 결과물을 뽑아내는 프로젝트가 대부분이다. 실리콘밸리도 예외는 아니다. 너무 바쁘다 보니 테스트를 만드는 시간은 사치처럼 여겨지기도 한다. 프로젝트 중간에는 요구사항도 바뀌고 로직도 바뀌면서 테스트도 덩달아 수정해야 하는 경우가 많이 생긴다. 이 시간조차 조차 아까우리라.
왜 자꾸 깨지는 테스트를 만들고 유지해야 하죠? 바빠 죽겠는데..
테스트가 깨졌다는 것은 내가 지금 무언가 위반하고 있다는 것을 알려준다. 잘못된 무언가는 빨리 알면 알 수 록 좋다. 릴리즈를 하기 전에 발견한다면 새벽에 온 콜을 받을 일이 없을 것이다. 따라서 다양한 종류의 테스트를 많이 만들수록 좋다!
단위 테스트를 모두 마친 후에 실제 동작을 확인해보면 디버거와 씨름하는 시간이 크게 줄어서 원하는 시간에 퇴근할 수 있게 해준다. 혹시 테스트하기 어려운 코드가 있다면 이는 리팩토링이 필요하다는 아주 강한 신호이다. 테스트가 깨지고 터지는 고귀한 희생 덕분에 우리는 랩탑 없이 휴가 갈 수 있게 됩니다! Woohoo!
지금 신에게는 아직 열두 개의 깨질 수 있는 테스트가 남아 있사옵니다.
버그가 발생할 확률은 매우 낮으나 미천한 테스트 들이 아직 깨지지 않았으므로
팀장님이 감히 우리를 주말에 출근시키지 못할 것입니다.
* 테스트 주도 개발에 대해서 몇 년 전에 작성했던 글을 공유합니다.