테스트 주도 개발

모든 것을 두 번 말함으로써 (코드와 테스트로 한 번씩) 자신감을 가지고 전진할 수 있을 만큼만 결함의 정도를 낮추기를 희망할 뿐이다.

1. 재빨리 테스트를 하나 추가한다
2. 모든 테스트를 실행하고 새로 추가한 것이 실패하는지 확인한다
3. 코드를 조금 바꾼다
4. 모든 테스트를 실행하고 전부 성공하는지 확인한다
5. 리팩토링을 통해 중복을 제거한다

1. 할일 목록을 작성하자
   • 작업을 시작하면 항목
   • 작업을 끝내면 항목
   • 또 다른 테스트가 생각나면 할일 목록에 추가한다
2. 객체를 만들면서 시작하는게 아니라 테스트를 먼저 만들어야한다
3. TDD가 경제적이기 위해서는 매일 만들어 내는 코드의 줄 수가 두 배가 되거나 동일한 기능을 구현하되 절반의 줄 수로 해내야 한다

TDD의 주기

1. 테스트를 작성한다: 원하는 인터페이스를 구상하고 어떤 식으로 사용되길 원하는지 본다.
2. “가능한 한 빨리” 실행 가능하게 만든다. 구현 디테일은 배제하고 일단 돌아가게 만들어본다.
   • 가짜로 구현하기: 상수를 반환시키고 단계적으로 변수로 바꾸어 나간다.
   • 명백한 구현 사용하기: 실제 구현 입력
3. “올바르게” 만든다. 중복 등을 제거하고 제대로 된 방식으로 소프트웨어를 만들어보자.
4. “작동하는”, “깔끔한” 코드를 얻기 위해 두 부분을 분리해야 한다. 그래서 TDD를 하며 먼저 “작동하는 코드” 부분을 해결하고 그 다음 “깔끔한 코드” 부분을 해결하는 것이다.
5. 할 일 목록이 빌 때가 그 때까지 설계한 것을 검토하기에 적절한 시기다

---

1. operation
   • 보통 메소드와 비슷한 의미로 쓰이며 객체가 수행할 수 있는 연산을 의미한다
2. stub implemnetation 스텁 구현
   • 메서드의 서명부와 반환 명령만 적는 식으로 해서 , 이 메서드를 호출하는 코드가 컴파일 될 수 있도록 껍데기만 만들어두는 것을 뜻한다