TestCancer design 2007년 12월 6일 Reactions

전업을 저자로 전환함에 따라, 시간이 갈수록 소프트웨어 개발 현장과 멀어져 가는 내 자신이 걱정된다. 다른 유명한 거장들이 현실과 동떨어진 모습을 본 적이 있는데, 내가 그와 동일한 불안감을 느끼고 있다. 이런 불안감과 싸우는데 가장 큰 도움이 되는 것은 바로 ThougtWorks다. 그곳에서 평상시처럼 현실감을 느낄 수 있다.

ThoughtWorks는 또한 현장의 아이디어를 얻을 수 있는 원천이며, 나는 동료들이 알아내거나 개발한 유용한 것들에 대해 글을 쓰는 것을 좋아한다. 보통 그것들은 나의 몇몇 독자들이 사용할 수 있길 바라던 유용한 아이디어들이었다. 나의 이번 주제는 그러한 선물과도 같은 주제는 아니다. 이번 것은 답변을 할 수 없는 문제에 관한 것이다.

그 시나리오는 다음과 같다. 우린 프로젝트를 고객으로부터 요청 받은 뒤 멋진 새로운 소프트웨어를 만들어 준다. 근래의 유행처럼, 이 소프트웨어에 대한 다양한 자동화된 테스트를 제공한다(보통 기능 코드의 라인 수 만큼의 테스트 코드가 존재한다.). 이런 테스트들은 보통 단위 테스트와 경계 기능 그리고 인수 테스트를 포함하고 있다. 두 방법의 테스트 모두 소프트웨어가 무엇을 하는지 그리고 소프트웨어를 개선시킬 때 어떤 버그가 발생하는지 빠르게 알아낼 수 있는 유용한 설명서다. 우린 이런 테스트들을 소프트웨어 시스템 개발을 성공시킬 수 있는 요소로써, 중요시하고 있다.

몇 개월 후에 우리는 행복한 고객으로부터 소프트웨어에 새로운 특징이나 기능을 추가하기 위한 작업 요청을 받게 된다. 그럼 작업에 돌입하고 문제가 있을 만한 부분을 중심으로 열심히 일하기 시작한다. 최소한 우리가 실수했을 만한 부분부터 말이다. 바로 그 순간 불쾌한 상황을 맞이하게 된다.

테스트가 더 이상 동작하지 않는다.

가끔 테스트가 빌드 스크립트에 포함되어있지 않아서, 몇 달 동안이나 실행된 적이 없을 수도 있다. 가끔 “테스트들”이 실행은 되지만, 그들 중 상당부분이 손실됐을 수 있다. 두 경우 모두, 우리의 중요한 테스트들을 엄청난 시간 소비를 야기하고 박멸하기조차 힘든 지독한 암에 걸리게 한다.

그럼 우린 대체 무슨 일이 발생했는지 물어보게 되고 “코드에 약간 손을 댔더니 테스트가 깨져서, 그 테스트들을 제거했습니다.”와 비슷한 답변을 듣게 된다. 여러분들은 이것을 우리의 실수라고 생각할 수 있다. 테스트에 대한 가치를 고객팀에게 충분히 설명하도록 관리하지 못했기 때문이다. 그냥 무시할 수 있는 것이 아니라 조사해야 할 필요가 있는 테스트가 무사히 통과하도록 하려면 더 많은 무언가를 해야 한다. 그러나 뭐라고 하든, 누군가는 이렇게 이야기할 것이다. 그런 테스트의 암은 흔히 발생하는 질병이라고.

테스트 암의 발생 원인이 테스트를 작성했기 때문이라고 생각하지 않는다. 비록 우리가 떠나자마자 맹독 기질이 있는 변경으로 인해 모든 테스트를 지워버렸다 하더라도, 그들의 가치는 이미 시스템을 개발할 때 얻을 수 있었기 때문이다. 그리고 테스트들이 항상 암에 걸리는 것은 아니다. 우리가 이미 수 년 전에 끝낸 시스템을 관리하고 있는 개발자로부터 자신이 TDD로 전향하게 되었다는 이야기를 들었다. 테스트는 우리의 코드가 다른 회사가 나중에 추가한 코드보다 더 쉽게 동작하도록 해준다.