26-빨간막대패턴

이 챕터에서는...

• 테스트를 언제 어디에 작성할 것인지

• 테스트 작성을 언제 멈출지에 대한 것

한 단계 테스트

목록에서 테스트를 고를때의 기준

• 새로운 무언가를 가르쳐줄 수 있으며, 구현할 수 있다는 확신이 드는 테스트를 고를것 (No 정답)

상향식, 하향식 둘다 TDD의 프로세스를 효과적으로 설명해 줄 수 없다.

1. 이러한 수직적인 관점 보다는, 성장이라는 단어를 보자.

   성장은 자기 유사성을 가진 피드백 고리 : 환경이 프로그램에 영향을 주고 프로그램이 다시 환경에 영향을 준다.

2. 상향, 하향이라는 방향보다는, 아는 것에서 모르는 것으로방향

아는 것에서 모르는 것으로 성장하는 프로그램을 갖는 것.

시작 테스트

어떤 테스트부터 시작하는 게 좋을까? 오퍼레이션이 아무일도 하지 않는 경우를 먼저 테스트.

새 오퍼레이션에 대한 첫 질문

• 이 오퍼레이션을 어디에 넣어야하지?

  • 이 질문에 답하기 전까지는 테스트에 뭘 적어야 할 지 알수 없을 것

  • 한 번에 한 문제만 해결하자는 의미에서 다른 질문은 다 빼고 이 질문만 생각할 방법은?

  • 만약 첫스텝에 현실적인 테스트를 작성한다면, 너무 많은 문제를 한꺼번에 해결해야하는 상황이 되어버림..

여러가지 문제들.
- 이 오퍼레이션을 어디에 두어야하나
- 적절한 입력값은 무엇인가
- 이 입력들이 주어졌을 때 적절한 출력은 무엇인가
이 문제들이 해결해야하는 상황이 되면, 너무 오랫동안 피드백이 없을 것

빨강/초록/리팩토링 이 것이 자주 반복되어야 한다.

...

• 결론: 작게

• 뭔가를 가르쳐 줄 수 있으면서도 빠르게 구현할 수 있는 테스트를 선택하라.

설명 테스트

• 자동화된 테스트가 더 널리 쓰이게 하려면 어떻게 해야할까? 테스트를 통해 설명을 요청하고 테스트를 통해 설명하라.

• 하라고 강제하면 안한다, 문제를 설명할 때 테스트를 통해 설명하라.

학습 테스트

• 외부 소프트웨어, 패키지의 새로운 기능을 처음 사용해보기전에도 테스트를 통해 잘 돌아가는 것을 확인할 수 있다.

133p, 144p와 관련 repl주도 test와 비슷한 점 (코드를 남겨두지 않는 것)이 있다.

또 다른 테스트

어떻게 하면 주제에서 벗어나지 않고 기술적인 논의를 계속할 수 있을까? 주제와 무관한 아이디어가 떠오르면 이에 대한 테스트를 할일 목록에 적어놓고, 다시 주제로 돌아올 것.

회귀 테스트

• 시스템 장애가 보고될때, 그 장애로 인해 실패하는 테스트, 그리고 통과할 경우엔 장애가 수정되었다고 볼 수 있는 테스트를 간단하게 작성하라.

• 회귀테스트란, 사실은 처음 코딩할 때 작성했어야 하는 테스트다.

  • 회귀테스트를 작성할 때는 이 테스트를 작성해야 한다는 사실을 어떻게 하면 애초에 알 수 있었을지 항상 생각해보아라

• 시스템 장애를 손쉽게 격리시킬수 없다면 리팩토링 해야한다. 이런 종류의 장애가 있다는 것은 설계가 마무리 안된 것.

휴식

• 지치고 고난에 빠졌을 때에는 쉬자!

• 데이브 응가의 샤워 방법론!

다시하기

• 길을 잃은 기분일 때에는, 코드를 다 지워버리고 처음부터 다시하라.

• 연관이 없는 사람과 짝프로그래밍을 하면 새로운 관점을 얻기도 함!

싸구려 책상, 좋은 의자!

TDD하기 좋은 물리적 환경을 만들자 ㅋㅋ