- 단위테스트가 만병통치약은 아니다 -
TDD나 Unit 테스트와 관련한 책들을 보면, 이를 하면 모든 것이 해결되는 것처럼 이야기한다.
특히나, 이러한 테스트를 통해서 모든 문제가 해결되다고 말한다.
물론, 이를 통해서 추후에 발생될 문제에 대해서 사전에 점검하는 차원에서는 분명히
필요한 것이 옮은 것임에는 분명하다.
한책에는 자신이 한 테스트에 대해서는 우선 믿어야한다라는 것으로
책의 시작부분을 다루고 있다. 이 책에서 말하듯 이러한 믿음 없이는 어떠한 테스트를
하더라도 시간낭비밖에 안될 수도 있다.
하지만, 지나친 믿음은 자칫 잘 못된 결과에 따른 추후에 큰 문제로 발생될 수 있다는
것도 이야기는 해야할 듯 싶다.
문제가 발생되더라도 단위테스트 소스들을 통해서 문제의 위치를 쉽게 찾아 고칠 수
있다고는 말하지만, 여기엔 크나큰 함정이 하나 있슴도 알아야 될 것이다.
이 단위테스트라는 것 또한 그냥 단순히 테스트를 만들 수 있는 것이 아니라는 점이다.
어떤 것을 테스트 해야하는지 어떤 결과가 나오는지에 대한 여러 환경적이거나 예측
할 수 있는 부분까지의 고려등이 반영이 되어야 된다는 점이다.
쉽게 말해서 "어설픈 단위테스트는(어설픈 테스트에 대한 설계) 안하니만 못하다"란 것이다.
단위테스트는 단순히 작은 단위로만 짤라서 그 기능만을 테스트 하는 것이라고 착각을
하기 쉽지만, 그 작은 조각이 전체에서는 핵심 부분이 될 수도 있는 것이기에 그러한
것까지도 많은 고민과 신경을 써야 한다는 것이다.
TDD나 Agile쪽에 이야기하듯 단위테스트는 마지막이 아닌, 테스트하면서 코드를
만들어나가는 것이라고는 하지만, 무작정 시작을 통한 코드와 내용을 추가는
조심해야할 부분이며 이것은 자칫 스스로의 무덤을 파는 길임을 잊지 말아야 한다는 것이다.
고객의 요구사항에 대한 분명한 청사진을 이해하고 기본적인 시나리오쯤은 인지하고
그리고 이에 대한 큰 흐름과 내용은 이해를 하고나서 그래도 기본적인 작업들이 이루어
져야 될 것이다. 물론 현업에서는 테스트코드부터 바로 뛰어드는 어리석은 작업을
하시는 분들이 없으리라 믿지만, 최근에 쏳아져 나오는 책들에는 이러한 것들에 대해서는
언급을 하고 있지 않기에 새롭게 이쪽에 대해서 시작을 하는 분들에게는 자칫 만병통치
약으로 믿었던 것에서 병을 얻게 되지 않을까 하는 생각에서 글을 써본다.
일단 일을 시작하는 것은 중요하지만, 그래도 한번쯤은 더 생각하고 실행하는 지혜 또한
잊지 말아야할 대목일 것이다.
혹시 또 오해가 있을지 몰라서 적자면,
단위테스트가 나쁘다라는 말은 아님을 분명히 밝힌다.
너무나도 훌륭한 방법중에 한가지이지만 자칫 잘못 생각할 수 있는 부분을
집고 넘어가고픈것 뿐이다.
TDD나 Unit 테스트와 관련한 책들을 보면, 이를 하면 모든 것이 해결되는 것처럼 이야기한다.
특히나, 이러한 테스트를 통해서 모든 문제가 해결되다고 말한다.
물론, 이를 통해서 추후에 발생될 문제에 대해서 사전에 점검하는 차원에서는 분명히
필요한 것이 옮은 것임에는 분명하다.
한책에는 자신이 한 테스트에 대해서는 우선 믿어야한다라는 것으로
책의 시작부분을 다루고 있다. 이 책에서 말하듯 이러한 믿음 없이는 어떠한 테스트를
하더라도 시간낭비밖에 안될 수도 있다.
하지만, 지나친 믿음은 자칫 잘 못된 결과에 따른 추후에 큰 문제로 발생될 수 있다는
것도 이야기는 해야할 듯 싶다.
문제가 발생되더라도 단위테스트 소스들을 통해서 문제의 위치를 쉽게 찾아 고칠 수
있다고는 말하지만, 여기엔 크나큰 함정이 하나 있슴도 알아야 될 것이다.
이 단위테스트라는 것 또한 그냥 단순히 테스트를 만들 수 있는 것이 아니라는 점이다.
어떤 것을 테스트 해야하는지 어떤 결과가 나오는지에 대한 여러 환경적이거나 예측
할 수 있는 부분까지의 고려등이 반영이 되어야 된다는 점이다.
쉽게 말해서 "어설픈 단위테스트는(어설픈 테스트에 대한 설계) 안하니만 못하다"란 것이다.
단위테스트는 단순히 작은 단위로만 짤라서 그 기능만을 테스트 하는 것이라고 착각을
하기 쉽지만, 그 작은 조각이 전체에서는 핵심 부분이 될 수도 있는 것이기에 그러한
것까지도 많은 고민과 신경을 써야 한다는 것이다.
TDD나 Agile쪽에 이야기하듯 단위테스트는 마지막이 아닌, 테스트하면서 코드를
만들어나가는 것이라고는 하지만, 무작정 시작을 통한 코드와 내용을 추가는
조심해야할 부분이며 이것은 자칫 스스로의 무덤을 파는 길임을 잊지 말아야 한다는 것이다.
고객의 요구사항에 대한 분명한 청사진을 이해하고 기본적인 시나리오쯤은 인지하고
그리고 이에 대한 큰 흐름과 내용은 이해를 하고나서 그래도 기본적인 작업들이 이루어
져야 될 것이다. 물론 현업에서는 테스트코드부터 바로 뛰어드는 어리석은 작업을
하시는 분들이 없으리라 믿지만, 최근에 쏳아져 나오는 책들에는 이러한 것들에 대해서는
언급을 하고 있지 않기에 새롭게 이쪽에 대해서 시작을 하는 분들에게는 자칫 만병통치
약으로 믿었던 것에서 병을 얻게 되지 않을까 하는 생각에서 글을 써본다.
일단 일을 시작하는 것은 중요하지만, 그래도 한번쯤은 더 생각하고 실행하는 지혜 또한
잊지 말아야할 대목일 것이다.
혹시 또 오해가 있을지 몰라서 적자면,
단위테스트가 나쁘다라는 말은 아님을 분명히 밝힌다.
너무나도 훌륭한 방법중에 한가지이지만 자칫 잘못 생각할 수 있는 부분을
집고 넘어가고픈것 뿐이다.
