테스트 주도 개발

인상 깊은 부분

25쪽

TDD란 프로그래밍 도중 내린 결정과 그 결정에 대한 피드백 사이의 간격을 인지하고, 또한 이 간격을 통제할 수 있게 해주는 기술을 말한다. “일주일간 종이에다 설계한 다음 코드를 테스트 주도로 개발한다면 이것도 TDD인가” 물론, TDD다. 결정과 그에 대한 피드백 사이의 간격을 인지하고, 또 의식적으로 제어했기 때문이다.

26쪽

동시성 테스트와 CSP

145쪽

TDD로 구현할 땐 테스트 코드이 줄 수와 모델 코드의 줄 수가 거의 비슷한 상태로 끝난다.

150쪽

“다음에 할 일이 무엇인가?“에 관련된 또 다른 질문은 “어떤 테스트들이 추가로 더 필요할까?“다.

155쪽

TDD의 부산물로 생기는 테스트들이 성능 테스트, 스트레스 테스트, 사용성 테스트를 대체할 수 있을거라고 예상하서는 안된다는 이야기

157쪽

테스트 커버리지를 향상시키는 또다른 방법은 테스트의 수는 그대로 두면서 프로그램의 로직을 단순화하는 것이다. 리팩토링 단계가 종종 다음과 같은 효과를 가져온다. 조건문이 메시징으로 바뀌거나 아예 사라진다.

189쪽

큰 딸 베싸니가 12살 때 처음 프로그래밍을 가르쳐 주었는데, 첫 프로그램 스타일로 TDD를 알려주었다. 딸애는 다른 사람들도 자기처럼 깨진 테스트 없이는 코드를 절대 입력할 수 없을 거라고 생각한다.

199쪽

xUnit의 정신은 간결함에 있다. 이에 대해 마틴파울러는 ‘소프트웨어 공학 역사에서 이토록 맣ㄴ은 사람이 이렇게 짧은 코드로 이토록 큰 은혜를 입은 적이 없었따.‘고 말했다.

210쪽

테스트를 먼저하면 스트레스가 줄고, 따라서 테스트를 더 많이 하게 된다.

215쪽

명백한 데이터가 주는 또다른 이점은 프로그래밍이 더 쉬워진다는 것이다. 명백한 데이터는 코드에 매직넘버를 쓰지 말라는 것에 대한 예외적인 규칙일 수도 있다.

222쪽

설명 테스트와 학습 테스트

226쪽

TDD는 웅가의 샤워 방법론을 정제한 것이다. 키보드로 뭘쳐야 할지 알면, 명백한 구현을 한다. 잘 모르겠다는 가짜 구현을 한다. 올바른 설계가 명확하지 않다면 삼가극량 기법을 사용한다. 그래도 모르겠다면 사워나 하러가는 거다.

231쪽

나의 경우, 테스트를 만들어놓고 보니 막상 이걸 통과시키려면 몇 가지를 한번에 수정해야만 하는 때에 이런 위기의 순간이 생기는데, 단 10분간만 빨간색이 지속되어도 겁이 난다.

239쪽

혼자서 프로그래밍 할때 프로그래밍 세션을 어떤 상태로 끝마치는게 좋을까? 마지막 테스트가 깨진 상태로 끝마치는 것이 좋다.

글을 쓸 때 문장 중간까지는 써놓고 멈추는 트릭도 설명

325쪽

만약 개발을 테스트로 주도하지 않는다면, 무엇으로 주도할 것인가? 추측(speculation)으로? 아니면 명세(specification)로? (이 두 단어가 동일한 워원을 갖는다는 사실을 아는가?)