엘키의 주절 주절

유닛 테스트를 내가 접한 지도 어언 10년이 다 되간다. 그간 내가 거쳐온 많은 회사에서 사용되기도, 무시되기도, 우선 순위에 밀리기도 하더라. 이 과정에서 제안도 여러 번 해보고, 설득 과정에서 자주 나왔던 질문이 있었다. 유닛 테스트하면 뭐가 좋은가요? 처음 이 질문을 받았을 당시, 내 답변은 테스트야 하면 당연히 좋은 거다 라고 답변했었다. 사실 누구나 테스트의 중요성은 배운다. 그래서 아주 작은 팀이고 여력이 부족하다면, 개발팀 내 테스트라도 소화하려고들 하는 것은 사실이긴 하다. 하지만 많은 사람들에게 테스트란 재미없고, 지루하지만 해야만 하는 교리 같은 것에 불과하다는 것이 문제다. 듣는 사람도 고개는 끄덕였지만, 막상 실천으로 이끌어 들이는 데에는 실패했다. 결과적으로 동기부여에 실패했다. ..

2000년대 중후반은 모두가 유닛 테스트에 미쳤다. 아니 TDD에 미쳤다.Test Driven Development에 대한 서적이 넘쳐났으며, 모두가 TDD를 통해 구원 받을거라는 희망찬 상상에 들떠 있었다. 이 붐을 주도했던 개발자중 한명인 DHH (rails를 만든 이)도 이 흐름에 동참했었다. 그를 비롯한 많은 이의 주장은 테스트 우선 신앙 (Test first fundamentalism)라 불릴 만큼 테스트를 바탕으로 코드를 작성하면 그 퀄리티가 비약적으로 상승 할 것이라는 의견이었다. 여지껏 내가 해온 테스트는 다음과 같았다. 독립적으로 동작할 수 있는 클래스에 대한 유닛테스트.- 화이트 박스 테스트로써의 유닛 테스트. (나는 크게 선호하진 않았지만, 가끔 진행했고 유닛테스트를 실천한 초반에 특..

사실 저는 테스트를 별로 좋아하지 않습니다. 테스터 분들이 보시면 기분나빠하실지도 모르지만, 개발보다 지루한 작업이기 때문이죠. 하지만 테스트는 언젠가 해야하고, 프로그램의 품질에 지대한 영향을 끼칩니다. 프로그래머는 모든 상황을 생각할 수 없습니다. 현재의 코드가 미칠 여파를 모두 생각해내는건 사실상 불가능하죠. 프로그래머의 논리적 빈틈은 테스트를 통해서 해결해야합니다. 그런 코드의 빈틈을 테스터에게만 맡길 수 있을까요? 그 프로그램을 작성한 사람보다 빈틈을 더 잘 찾을 수 있을까요? 프로그래머가 하는 테스트가 꼼꼼하다면 프로그램이 공개 되고 나서 발생할 문제를 상당수 방지 하거나 해결 할 수 있습니다. 테스트 주도 개발은 기본적으로 리팩토링을 기반으로 이루어집니다. 테스트를 통해 개발을 하며, 리팩토..