리팩토링 스터디 #2.5 - 내용 미리보기

리팩토링 스터디도 3주차가 다가오고 있습니다. 추석 기간 동안의 휴식을 고려해 이번 주차는 양이 그리 많지 않네요. 챕터 4 - 테스트 구축하기부터 챕터 5 - 리팩터링 카탈로그 보는 법까지 예정되었습니다. 본문의 내용을 정리하는데에도 시간이 많이 걸리지 않았으니, 바로 시작하겠습니다.

 

테스트 코드

저자는 리팩터링은 가치있는 도구이지만, 그것만으로는 부족하다고 말합니다. 리팩터링을 하는 근본적인 이유는 작업 시간의 단축으로 인한 효율적인 개발이라고 지난 회차에서 정리했었는데요. 이러한 작업 시간 단축을 위해 필요한 것이 바로 견고한 테스트 스위트(test suite)입니다.

 

 

테스트의 중요성은 아무리 강조해도 부족하지 않습니다

 

단순히 한 번 쓰고 버릴 테스트 코드로 끝나는 것이 아닌 지속 가능한 테스트 스위트를 만들어 내는 것은 중요합니다. 프로그램이 제대로 작동하는지 검사하는 가장 좋은 방법인 테스트는 사실 그리 어렵지 않습니다. 다만 상당히 지루한 과정의 반복일뿐이죠. 함수의 결과값을 일일히 콘솔에 찍어보거나, 가끔 이 함수 저 함수 복잡하게 꼬여있는 기능을 테스트할때면 코드 덩어리들을 여기저기 만져줘야합니다. 

 

단순 테스팅 작업에 피로함을 느꼈던 저자는 이러한 작업을 조금이라도 줄이기 위해 눈으로 직접 확인하기보다 컴퓨터에게 맡기는 방법을 선택하게됩니다. 의도했던 결과 값과 컴퓨터가 테스트한 값이 같은지 비교하고 그 결과만 받기로 했던 것이죠. 테스트 작업에 드는 시간과 노력이 확연히 줄어든겁니다. 이것이 자가 테스트 소프트웨어의 탄생 과정입니다.

 

하지만 이것은 단순히 테스트에 들어가는 시간과 비용을 줄인 것 뿐입니다. 여전히 테스트의 필요성에는 의문 부호가 붙어있습니다. 사실 가장 중요한, 전체적인 작업 시간을 획기적으로 줄일 수 있던 이유는 디버그 과정의 개선입니다.

 

 

디버그

들어가는 시간이 줄어드니 부담없이 테스트를 진행할 수 있었습니다. 컴파일 한 번에 테스트 한 번을 하더라도 비교적 적은 비용으로 결과를 확인할 수 있으니까요. 사실상, 여기서부터가 디버그 과정의 시작입니다.

 

기능을 하나 완전히 개발하고 나서 테스트를 수행했습니다. 그러나 이 기능은 안타깝게도 알 수 없는 문제로 인해 원하던대로 작동하지 않았습니다. 개발자들은 이 문제의 원인을 찾기 시작합니다. 처음부터 끝까지 로직을 재검토하고, 잘못 구현된 부분은 없는지, 누락된 부분이 있는 것은 아닌지 검사하기 시작하죠. 결국 코드의 처음부터 끝까지 쥐잡듯 뒤진 끝에 문제를 찾아내었습니다. 디버그 과정에만 온전히 몇 시간 정도를 투자한겁니다.

 

그렇다면, 위에 언급한대로 매 컴파일마다 테스트를 거쳤을 경우라면 어떨까요?

 

작은 단위의 코드를 구현하고 컴파일과 동시에 테스트를 수행합니다. 그러던 중 방금 작업했던 코드에서 미처 생각하지 못했던 버그를 발견합니다. 개발자는 버그가 발생하기 직전으로 돌아가 에러의 원인을 파악하고 수정합니다. 이를 회귀 버그(regression bug)를 잡는다고 표현합니다. 위의 과정이 몇 번 더 반복되었고, 기능이 완전히 개발되었을때는 오류가 발생하지 않은 깨끗한 코드가 완성되었습니다.

 

중간중간 테스트를 하는 시간과, 에러를 해결하는데 사용된 시간은 단 몇 분이었습니다. 

 

매번 테스트를 거쳤던 아래의 경우 회귀 버그를 잡는데에 걸리는 시간을 모두 합쳐도 위의 경우와 큰 차이가 납니다. 방금 전까지 작업하던 내용이기 때문에 개발자가 어떤 흐름인지 명확하게 기억하고 있고, 그만큼 작업하기에도 수월하기 때문입니다.

 

여기에 더 나아가서 켄트 백은 구현 후 테스트가 아닌, 테스트 케이스 작성 후 구현이라는 개발 기법을 창시해냅니다. 이를 테스트 주도 개발, TDD라고 부릅니다. 테스트 - 코딩 - 리팩터링의 과정을 한 시간에도 여러 차례 진행하기 때문에 중간에 길을 잃지 않고, 동시에 높은 생산성을 가지고 코드를 작성할 수 있게 됩니다.

 

높은 생산성과 방향성을 동시에 잡는 TDD

결론

결국 테스트 또한 저자가 일관되게 말해왔던 효율의 시점에서 바라보았을때 이익이 있기 때문에 취하는 것입니다. 아무리 테스트가 좋고 사랑한다고 한들 굳이 이러한 시스템을 만들어 놓을 필요가 없는 자그마한 코딩에까지 넣을 필요는 없다는 뜻이죠.

 

제품 코드보다 테스트 코드를 수정하는 데 시간이 더 걸린다면, 그리고 테스트 때문에 개발 속도가 느려진다고 생각되면 테스트를 과하게 작성한건 아닌지 의심해보자.

 

책에서도 말했듯이, 배보다 배꼽이 더 큰 경우에는 구태여 자잘한 테스트를 넣을 필요는 없습니다. 물론, 테스트가 너무 많은 경우보다는 너무 적은 경우가 훨씬 훨씬 많으니 너무 걱정하지 않으셔도 됩니다.

 

챕터 5 - 리팩터링 카탈로그 보는 법은 이후부터 나올 리팩터링 기법들을 설명하는데 필요한 도구여서 굳이 포스팅에 옮기지는 않겠습니다. 그럼, 본편에서 다시 뵙겠습니다.