TDD의 다섯가지 전제

다음 트위터를 번역한 글입니다.

여기에 TDD의 잘 알려지지 않은 5가지의 전제 사항이 있습니다.

왜 잘 알려져지 않았냐? 글쎄 그 전제들은 언제나 있었습니다. 하드코어한 TDD’er들은 스스로를 모델링하고 있습니다만, 그들에게 관심이 주어진적이 없었던것 같습니다.

나는 TDD 코치와 선생들에게 “어떤것이 단언 assert인가!”라는 엄격한 규칙 시스템에서 한걸음 물러나, 자신들의 작업에서 저 전제들을 강조했으면 합니다.

1) 비용 전제(Money Premise): 우리는 돈때문에 TDD를 합니다. 의도적으로 우습게 이야기 하는것 같지만, 제가 의미하는 것은 다음과 같습니다.

저는 하나의 이유때문에, 그리고 오직 그 이유하나 때문에 TDD를 수행합니다. 더 빠르게 기능을 구현 하는 것입니다. 더 빠른 기능구현이 내 직업입니다. TDD는 그렇게 합니다.

여러 다른이유들로 TDD를 할수 있습니다만, 대체로 그 이유들은 TDD를 하는 이유가 될수 없습니다.

나는 예술을 위해, 지적 순결성을 위해, 도덕성을 위해, 좋은 시민이기 위해 심지어 품질을 위해서도 TDD를 하지 않습니다.

내가 테스트를 작성할때, 테스트를 작성하는 것이 기능 구현을 좀더 빨리 작성할수 있게 해주기 때문에 작성합니다. 오직 그 이유 뿐입니다.

내가 테스트를 작성하지 않을때는, (어떤 이유에서) 테스트를 작성하는 것이 기능 구현을 더 빠르게 해주지 않기 때문입니다.

2) 판단 전제(Judgement premise): 잘 동작하는 코드를 만들어 내는 계산가능한 알고리즘은 없습니다. TDD를 수행하는 긱(Geek) 들을 항상 개인적인 판단을 사용합니다.

우리는 개인적인 판단을 이용해 테스트를 작성할지 않할지, 언제 더 빠른 테스트를 작성할지 않할지, 문제를 어떻게 테스트 가능하게 연결할지 등등 을 결정합니다

TDD를 어떻게 수행하는가에 대한 플로우차트들이 있지만, 기껏해야 훈련용일 뿐입니다. 그런 플로우차트들은 내가 하는 일의 핵심적인 부분을 빼놓기 때문입니다. 나는 TDD’er 이지 TDD 알고리즘이 아닙니다.

우리는 영구적으로, 절대적으로, 불가피하게, 그리고 행복하게 TDD’er로서의 개인적인 판단에 의존합니다.

3) 체인 전제(Chain premise): 체인을 테스트하는 가장 좋은 방법은 링크마다 테스트하는 것입니다.

이 전제는 우리의 큰 응용 프로그램의 아주 작은 하위 시스템을 테스트하기 위한 우리의 거대한 선호에 기초를 둡니다.

함수가 A -> B -> C -> D의 사슬을 포함하고 우리 자신을 만족 시킨다면 B가 작동하면 A가 작동합니다. C가 작동하면 B가 작동합니다. 그렇게 진행됩니다…

우리는 ABCD 가 작동한다는 만족 시키는것에 매우 가까워 졌습니다.

“그렇죠, 하지만 “ 이라고 말하는 소리가 귓가에 들리는거 같네요. 주의깊게 읽으세요: 매우 가깝다

왜 그렇게 가까이 다가 왔습니까? 단일 링크 테스트는 대규모보다 읽기, 스캔, 쓰기 및 실행이 훨씬 쉽기 때문입니다.

그리고 기억해둘것: 나는 비용 때문에 이렇게 합니다. 대규모의 테스트를 읽고 작성하는데 소비하는 시간에, 이런 작은 단일 링크 테스트를 읽고 작성하는 사이클이 기능 개발들 더 빠르게 해줄수 있기 때문에 사용합니다.

체인 전제는 선호에 관한 것이지 규칙이 아닙니다. 나는 서브 시스템을 테스트하거나, 서브 시스템을 통해서 테스트 하기도 합니다.

하지만 체인 전제가 우리가 동작함을 증명할수 있는 가장 작고 가벼운 서브시스템을 만들어 내는 경향이 있습니다.

4) 연관 관계 전제(Correlation premise): 내 코드의 내부 품질(Internal Quality. IQ)은 내 작업의 생산성과 직접적으로 관련이 있습니다.

외부 품질 (EQ) 대 내부 (IQ)에 대해 할말이 매우 많지만, 간단하게 요약만 하겠습니다.

EQ는 최종 사용자가 감지 할 수 있습니다. IQ는 소스가 있는 프로그래머만 감지 할 수 있습니다.

연관 관계 전제는 EQ와 IQ를 혼동하는 사람들에게는 어렵게 느껴질 것입니다.

간단히 말하자면, 기능을 더 빨리 구현하는 것과 EQ를 타협할수 있습니다. 할수 있지요. 고객이 내가 기능 구현을 더 빨리 하기만하면, 그 기능이 얼마나 느려터졌는지 신경 않쓴다면 말이죠….

고객이 구현이 얼마나 지저분한지 신경 쓰지 않느다면, 더 빨리 구현할수 있습니다. 구현이 도메인의 규칙과 일치하는지 별로 신경 않쓴다면, 더 빠르게 구현할수 있습니다.

자신의 일상적인 생산성이 어떤 공식으로 되어있는지 . 두가지 가장 중요한 요소는 1) 내 스킬 2) 도메인의 복잡성 입니다.

나의 기술도, 도메인 복잡성도 바꿀수 없다면, 다음으로 중요한 요소는 무엇일까요? 나의 생산 기능을 지배하는 것이 무엇일까요?

그것은 내가 다룰 재료의 품질입니다. 여기가 연관 관계 전제가 적용 되는 곳입니다.

5) 마지막으로 운전 전제(Driving premise). 테스트와 테스트 가능성은 설계의 1등급 관여자입니다.

우리가 설계할때 우리는 여러 1등급 요소를 고려해야 합니다. TDD’er가 아닌 사람이나 초보자는 “작동할 것인가”와 “빠를 것인가”에 집중할 것입니다.

하지만 운전 전제는 세번째 일등급 질문이 “테스트 할수 있는가”라고 이야기합니다. 테스트와 테스트 가능성에 대한 고려는 코드의 모양을 형성합니다.

젊은 사람들이 TDD에 도달하는 것을 가로 막는 가장 큰 장애물은 쉽게 테스트 할 수 있도록 디자인을 변경하지 않으려고 하는 것입니다.

운전 전제는 우리가 쉽게 테스트 할수 있도록 디자인을 변경해야 한다는 이야기입니다. soft-TDD와 hard-TDD에 대해 따로 이야기 하겠습니다만, 어쨌든 우리는 그렇게 해야합니다.

이렇게 5가지의 전제는 TDD’er가 하는 거의 모든 행위의 기반이 됩니다. 그리고 이것들은 모두 개인의 취향과는 무관한 것들입니다. 학교에서도 충분히 가르칠만한 것들이죠.

우리는 비용 때문에 TDD를 합니다. 우리는 인간의 판단에 의존합니다. 각 링크별로 체인을 테스트합니다 우리는 내부품질(IQ)를 높게 유지합니다. 우리는 테스트 가능성을 가진 디자인을 만듭니다.

코치하고 가르치는 나의 친구들, 오늘 일을 하고 있다면, 당신이 사용하는 전제(premise)에 대해 사람들에게 이야기 해주십시오.

우리는 규칙으로 가득찬 가짜 체계를 과거로 돌리고, TDD의 핵심으로 옮겨 가야 합니다

Like what you read? Give Jisung, Ahn a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.