[역자의 글]
켄트백 - 테스트 주도 개발은 하나의 기술이지만 그 이면에는 사고의 근원적 변화가 있습니다. 데밍(W.E Deming)은 품질에 대한 책임을 그 누구보다도 작업자에게 맡겨야 한다고 주장했습니다. ... 프로그래머가 자기 작업의 품질에 대한 우선적 책임을 져야 한다는 깨달음이죠. TDD를 실천법으로 적용하는 것은 도움이 될 수 있습니다만, 책임을 맡는 방법으로 사용하면 강력해질 것입니다.
김창준 - ... 자신의 생각과 컴퓨터가 보여주는 것이 서로 다르다고 해서 절대 낙심하지 마세요. 다름을 느끼고 즐기려고 하세요. 빨리 테스트를 통과시키려고, 혹은 프로그램을 빨리 작성하려고 너무 조바심 내지 마세요. 자신감을 가지세요. TDD를 쫓아가려고 하지 마시고 TDD가 자신을 따라오게 하세요. ...
TDD의 특성상 완성된 프로그램 코드를 보거나, 간단한 매뉴얼 정도로는 TDD를 익힐 수 없습니다. 그 과정을 하나 하나 따라가야 합니다.
[TDD 수련법]
-간단하고 쉬운 문제들을 TDD로 시도합니다.
-초록 막대 주기는 가능하면 짧도록 합니다. (초록 막대 주기 : 초록 막대가 나오는 시점에서 다음 초록 막대가 나오는 시점까지의 시간)
-이때 초록 막대 주기의 최대 시간을 정해놓고 진행하다가 시간을 초과하면 직전 초록 막대 상태로 돌린 다음(그 동안의 코드는 포기하고) 새로 시작하는 것이 좋습니다.
-‘진짜로 만들기 전까지만 가짜로 구현하기’. 가짜로 구현하기는 초록 막대 주기가 짧아지는 가장 간단하고 빠른 방법입니다.
-여유를 가지세요. 모든 학습과 개선의 필수적 요소는 자기를 돌아보기(self-reflectivity)와 자기가 생각하는 것을 생각하는 메타인식(meta-congnition)입니다.
[한국어판 인터뷰]
켄트백 - 린 생산(Lean Manufacturing)에서는 두 가지 낭비에 대해 이야기합니다. 아무도 보지 못했고, 또 제거하려고 노력하지 않았기 때문에 순수한 낭비가 존재합니다. 대기 시간은 전형적인 순수 낭비입니다. 필요한 낭비는 현재 당신이 꼭 해야 하지만 사실 아무 가치도 추가되지 않는 활동들에서 옵니다. 최소한, 결함 수준이 지나치게 높은 한 검사는 필요 낭비입니다. ... TDD에서 테스트를 작성하는 데 드는 시간의 일부는 필요 낭비입니다. ... 테스팅에 쓰는 시간 일부는 사실 분석 혹은 설계 결정에 쓰입니다. 이것은 낭비가 아닙니다. 하지만 테스트 작성에 드는 시간은 제거 후보입니다. ...
제가 테스트를 작성하지 않는다면, 그건 제가 그렇게 할 수 없다고 생각하기 때문입니다. 잠시 공포를 느끼는 것은 테스트를 어떻게 작성할지 알아내는 충분한 동기가 됩니다.
[저자의 글]
작동하는 깔끔한 코드(clean code that works) - Ron Jeffries
테스트 주도 개발의 궁극적인 목표다.
예측 가능한 개발 방법이다. 끊임 없이 발생할 버그에 대해 걱정하지 않아도 된다.
테스트 주도 개발에서는 두 가지 단순한 규칙만을 따른다.
-오직 자동화된 테스트가 실패할 경우에만 새로운 코드를 작성한다.
-중복을 제거한다.
<기술적 함의>
-매 결정사항에 대해 피드백을 제공하는 실행 가능한 코드를 기반으로 하는 유기적인 설계
-자동화된 테스트. 직접 테스트를 작성해야 한다.
-개발 환경은 작은 변화에도 빠르게 반응할 수 있어야 한다.
-테스트를 쉽게 만들려면 반드시 응집도는 높고 결합도는 낮은 컴포넌트들로 구성되게끔 설계해야 한다.
1.빨강-실패하는 작은 테스트를 작성한다.
2.초록-빨리 테스트가 통과하게끔 만든다. 어떤 죄악을 저질러도 좋다.(죄악이란 기존 코드 복사해서 붙이기, 테스트만 간신히 통과할 수 있게끔 함수가 무조건 특정 상수를 반환하도록 구현하기 등을 의미)
3.리팩토링-중복을 제거한다.
실패하는 테스트를 통과시키기 위해 필요한 만큼만 코딩하는 것은...
품질보증(QA)을 수동적인 작업에서 능동적인 작업으로 전환할 수 있다.
소프트웨어 엔지니어들은 일일 단위 혹은 주 단위의 협력 대신 분 단위로 협력하면서 일할 수 있다.
새 기능의 선적 가능한 소프트웨어를 매일 갖게 된다.
<용기>
테스트 주도 개발은 프로그래밍하면서 나타나는 두려움을 관리하는 방법이다. “정말 어려운 문제라서 시작 단계인 지금은 어떻게 마무리될지 알 수 없군.”하고 생각하는 식의 합리적인 두려움을 말한다.
-두려움은 여러분을 망설이게 만든다.
-두려움은 여러분이 커뮤니케이션을 덜 하게 만든다.
-두려움은 여러분이 피드백 받는 것을 피하도록 만든다.
-두려움은 여러분을 까다롭게 만든다.
⇒불확실한 상태로 있는 대신, 가능하면 재빨리 구체적인 학습을 하기 시작한다.
⇒침묵을 지키는 대신, 좀더 분명하게 커뮤니케이션한다.
⇒피드백을 회피하는 대신, 도움이 되고 구체적인 피드백을 찾는다.
테스트 주도 개발의 테스트는 일단 테스트 하나를 작동하게 하면, 그게 지금 현재 그리고 앞으로 영원히 작동할 거라는 걸 알 수 있다.
TDD는 XP방식처럼 절대적이지 않다.
TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다.
이 책을 끝까지 읽고 나면...
-단순하게 시작하고
-자동화된 테스트를 만들고
-새로운 설계 결정을 한 번에 하나씩 도입하기 위해 리팩토링
분명하고 직접적인 프로그래밍 세상. 복잡한 해법이란 없고 단지 외관상 복잡해 보이는 문제에 대해 신중히 사고하면 되는 그런 곳. TDD는 바로 그런 사고가 가능하도록 당신을 도와줄 수 있다.
[들어가는 글]
비지니스 가치를 만들어 내는 요소
-방법:시스템의 설계를 조금씩 성장시키는(growing) 지속적 경험이 필요
-동기:외적으로 불가능해 보이는 작업을 시작할 용기
-기회:포괄적이고 자신감을 만들어 내는 테스트들, 잘 리팩토링된 프로그램, 설계 결정을 분리할 수 있는 프로그래밍 언어
자기 프로젝트의 가치를 기술적인 마술을 사용해서 몇 배로 늘릴 수 있는 동기를 갖는다는 것은 스스로 제어할 수 있는 문제가 아니다. 이와는 달리, 방법과 기회는 당신이 완전히 제어할 수 있다.
테스트 주도 개발은 소프트웨어 엔지니어 누구라도 따를 수 있는 기술로, 단순한 설계와 확신을 불어 넣는 테스트 슈트를 만들도록 격려한다.
댓글