들어가면서..
우테코 프리코스를 하면서 코치님 중 한 분이 이런 말씀을 하셨다. "2주차 미션부터는 함수나 메서드들을 역할에 따라서 분리하는 연습과, 테스트 도구를 연습하는 시간이 되었으면 좋겠어요. 우테코에서는 테스트를 중요시 하고 있어요. 단순히 정상 동작하는 지 테스트 하는 것이 아니라 테스트 주도 개발(TDD) 이 주는 이점에 대해 공부하고 생각해 보시면 좋을 듯합니다." 이 말을 듣고 테스트 주도 개발이라는 말이 나에게는 크게 와닿지 않고, 붕 떠있는 느낌이라 이 책. "테스트 주도 개발"이라는 책을 읽어보며 테스트 주도 개발이란 무엇이고, 어떻게 해야하는지 알아가고자 한다.
저자의 글이 너무 인상깊어 기록하고 싶은 부분이 있어서 저자의 글부터 정리해보려고 한다.
저자의 글
테스트 주도 개발의 궁극적인 목표 : 작동하는 깔끔한 코드.
그럼 작동하는 깔끔한 코드가 왜 훌륭한 목표일까?
이유는 다음과 같다.
- 예측 가능한 개발 방법이다. 끊임없이 발생할 버그에 대해 걱정하지 않고, 일이 언제 마무리될 지 알 수 있다.
- 코드가 가르쳐주는 모든 교훈을 학습할 기회를 갖게 된다. 처음 생각나는 대로 후딱 완료해 버리면 두 번째 것 , 더 나은 것에 대해 생각할 기회를 잃게 된다.
- 당신이 만든 소프트 웨어는 사용자의 삶을 향상시켜 준다.
- 동료들이 당신을 존경할 수 있게 해주며, 당신 또한 동료들을 존경할 수 있게 된다.
- 작성하는 동안 기분이 좋다.
그러면, 어떻게 하면 작동하는 깔끔한 코드를 얻을 수 있을까?
많은 요인들이 우리를 깔끔한 코드에서 멀어지게 만들고, 작동하는 코드조차 만들기 힘들게 한다. 두려움에 대해 오랫동안 상의하는 대신, 해야 할 것이 있다. 자동화된 테스트로 개발을 이끌어 간다. 이런 개발 방식을 테스트 주도 개발이라 부른다. 테스트 주도 개발에서는 두 가지의 단순한 규칙만을 따른다.
- 오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
- 중복을 제거한다.
왜 이런 식으로 작업해야 할까?
왜 소프트웨어 엔지니어가 자동화된 테스트를 만드느라 추가 작업을 해야 하는 걸까? 왜 엄청나게 복잡한 설계를 머릿속에서 그려낼 수 있는 소프트웨어 엔지니어 들마저 작은 단계를 종종걸음으로 밟아나가야만 하는가?
용기 때문이다.
테스트 주도 개발은 프로그래밍하면서 나타나는 두려움을 관리하는 방법이다. 여기서 두려움이란 나쁜 의미의 두려움을 뜻하는 것이 아니고, "정말 어려운 문제라서 시작 단계인 지금은 어떻게 마무리될지 알 수 없군." 하고 생각하는 식의 합리적인 두려움을 말한다. 만약 고통이라는게 자연이 우리에게 보내는 '멈춰" 라는 신호라면, 두려움은 "조심해."라는 신호로 생각할 수 있다. 조심은 좋은 것이지만 두려움은 다음과 같은 일의 원인을 제공하기도 한다.
- 두려움은 여러분을 망설이게 만든다.
- 두려움은 여러분이 커뮤니케이션을 덜 하게 만든다.
- 두려움은 여러분이 피드백 받는 것을 피하도록 만든다.
- 두려움은 여러분을 까다롭게 만든다.
이 중 어떠한 것도 프로그래밍에 도움이 되지 않는다. 특히 어려운 코드 를 짤 때는. 이제 문제는 우리가 어려운 상황에 어떻게 맞설 것인지와 아래의 것들이라 할 수 있다.
- 불확실한 상태로 있는 대신, 가능하면 재빨리 구체적인 학습을 하기 시작한다.
- 침묵을 지키는 대신, 좀 더 분명하게 커뮤니케이션한다.
- 피드백을 회피하는 대신, 도움이 되고 구체적인 피드백을 찾는다.
- (자신의 나쁜 성깔을 직접 해결해야 한다.)
테스트 주도 개발은 다음과 같다. 일단 테스트 하나를 작동하게 하면, 그게 지금 현재 그리고 앞으로 영원히 작동할 거라 는 걸 알 수 있다. 테스트가 망가져 있을 때에 비해, 이제 모든 것이 작동 하는 쪽으로 한 걸음 더 가까이 있다. 이제 다음 테스트를 작동하게 하고, 그 다음, 또 다음... 비유하자면, 프로그래밍 문제가 어려울수록 각각의 테스트는 좀더 작은 부분을 커버해야 한다.
1부. 화폐 예제
TDD의 리듬
- 재빨리 테스트를 하나 추가한다.
- 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다.
- 코드를 조금 바꾼다.
- 모든 테스트를 실행하고 전부 성공하는지 확인한다.
- 리팩토링을 통해 중복을 제거한다.
앞으로 TDD를 알게되면서 놀랄 것을 예상해보면...
- 각가의 테스트가 기능의 작은 중가분을 어떻게 커버하는지
- 새 테스트를 돌아가게 하기 위해 얼마나 작고 못생긴 변화가 가능한지
- 얼마나 자주 테스트를 실행하는지
- 얼마나 수 없이 작은 단계를 통해 리팩토링이 되어가는지
이제 놀랄준비를 해보자-
