32장. TDD 마스터 하기

 

단계가 얼마나 커야하나?

( 각 테스트가 다뤄야 할 범위는 얼마나 넓은가? / 리팩토링 하면서 얼마나 많은 중간단계를 거쳐야 하는가? )

 

리팩토링 초기에는 작은 단계로 작업

많은 작은 리팩토링 작업후 몇단계 건너뛰는 시도.

자동화된 리팩토링 IDE 툴 활용.

 

테스트 할 필요가 없는 것은 무엇인가?

 

'두려움이 지루함으로 변할때까지 테스트를 만들어라'

 

다음것들을 테스트 해야함.

-> 조건문, 반복문, 연산자, 다형성.

 

내가 작성한 코드에 대해서만 테스트 할것.

불신한 이유가 없다면 다른사람이 만든 코드를 테스트하지마라.

-> 다른 코드가 바뀐다면 테스트가 실패할것이기때문

 

좋은 테스트를 갖췄는지의 여부를 어떻게 알 수 있는가?

 

설계문제가 있을을 알려주는 테스트 속성.

- 긴 셋업코드

- 셋업 중복

- 실행시간이 오래 걸리는 테스트

- 깨지기 쉬운 테스트

 

TDD로 프레임 워크를 만들려면 어떻게 해야하나?

- 단순하고 직관적으로 첫번째 기능을 구현

- 첫번째 기능에 대한 변주가 되는 두번째 기능을 구현. 중복은 한곳으로 모이고, 다르부분은 다른곳으로 이동.

- 앞의 두 기능에 대한 변주로 세번째 기능 구현. 공통의 로직은 약간의 수정만을 통해 재활용 가능한 상태로.

 

개방-폐쇄 원칙 (객체는 사용에 대해 열려있어야하고 향후 수정에 대해서는 닫혀있어야 함.)

 

피드백이 얼마나 필요한가?

테스트를 얼마나 작성할지 고려할때 실패간 평균시간(Mean Time Between Failures 실패하는 시점간의 평균시간차)을 고려.

 

정말 일어날 것 같지 않은 조건과 그 결합을 테스트할지

 

TDD의 테스트에 대한 관점은 실용적.

TDD의 테스트는 어떤 목적을 위한 하나의 수단.

 

테스트를 지워야 할 때는 언제인가?

- 첫째 기준은 자신감.

   삭제할 경우 자신감이 줄어들것 같으면 지우면 안됨.

- 둘째 기준은 커뮤니케이션.

   두개의 테스트가 코드의 동일한 부분을 실행하더라도 다른 시나리오를 말한다면 남겨둠.

 

프로그래밍 언어나 환경이 TDD에 어떤 영향을 주는가?

TDD주기를 수행하기 힘든 언어나 환경에서 작업하면 단계가 커지는 경향이 있음.

- 각 테스트가 더 많은 부분을 포함하게 만듬

- 중간 단계를 덜 거치고 리팩토링 함.

 

TDD주기를 잘 지원하는 언어와 환경에서는 더 많은 실험이 가능.

 

거대한 시스템을 개발할 때에도 TDD를 할 수 있는가?

시스템에 있는 기능의 양은 TDD의 효율에 영향을 미치지 않음.

중복을 제거함에 더 작은 객체들이 만들어지고,

애플리케이션 크기와 무관하게 독립적으로 테스트 될수 있음.

 

애플리케이션 수준의 테스트로도 개발을 주도할 수 있는가?

사용자가 직접원하는 바를 테스트

테스트를 작성하는 것은 사용자에게 새로운 책임이 부여되는것

 

애플리케이션 고정물 fixture 만들기의 기술적문제

사용자 작성 테스트 주변의 조직 변화 이슈들을 다루는것

단일 단계 체스트 규칙 적용.

 

프로젝트 중반에 TDD를 도입하려면 어떻게 해야 할까?

우선 해야할 일은 변경의 범위를 제한하는 것.

 

그리고 테스트와 리팩토링 사이에 존재하는 교착상태 deadlock을 풀어주는것.

 

전체적인 레벨에서 피드백을 얻은 후 

 

자꾸어야 하는 부분이 변화에 좀더 수용적이 되게 함.

 

TDD는 누구를 위한 것인가?

TDD는 더 나은 코드를 작성한다면 좀더 성공할 것이라는 순진하고 geek한 태도에 근거.

더 깔끔한 설계를 할 수 있도록, 설계를 개선하며 적절한 문제에 집중할 수 있게 도와줌. 

 

프로젝트가 80%만 어느정도 적당한 수준으로 엔지니어되어도 성공이하고 할 수있지만,

TDD는 통용되는 수준보다 월씬더 깨끗한 설계의 코드를 더 적은수의 결함으로 구현되게 만듬.

 

'엄청난 흥미를 가지고 새 프로젝트를 시작해서 시간이 지남에 따라 서서히 코드가 썩어가는걸 보게된다.'

 

테스트가 쌓여감에 따라 코드에 대한 자신감이 생기며 설계를 개선해나가면서 점점 더 많은 설계변경을 가능하게 함.

 

TDD는 초기 조건에 민감한가?

테스트 할때 특정한 순서 (빨강-초록-리팩토링)로 진행시 매끄럽게 진행되지만,

같은 테스트를 다른순서로 해보면 나아갈 방법이 보이지 않기도 함.

 

TDD와 패턴의 관계는?

예외 혹은 규칙의 어느것도 들어맞지 않는 문제가 있을경우,

새로운것을 창조하고 적용할 더 많은 시간과 에너지를 갖게된다.

 

패턴 주도 설계에 대한 구현 방법으로써의 TDD

 

완벽하게 사리에 맞는 설계가 결국은 틀린것으로 판명나기도 함.

그냥 시스템이 무슨일을 할지 생각하고 나중에 설계가 알아서 정해지도록 하는것이 더 낫다.

 

어째서 TDD가 잘 작동하는가?

이 결과의 일부는 분명 결함 감소에서 온다. 결함을 빨리 발견해 고칠수록 비용은 낮아짐.

새로 릴리즈한 시스템이 더이상 새로운 버그의 근원지가 아님.

 

설계 결정에 대한 피드백 고리를 단축시킴.

 

모든 기능에 대해 단위 테스트를 작성한다면, 

각 단계사이에서 코드 단순화를 위해 리팩토링 한다면,

한번에 하나씩 기능을 추가하고 모든 단위 테스트가 통과한 후에 추가한다면,

모든 흐름이 그곳으로 수렴하는 상태 공간의 점. 끌개 attractor를 만들어 내게 될것.

 

코드가 시간이 지남에 따라 더 나빠지기보다 더 좋아지도록하는 경향이 있다.

 

이름을 테스트 주도 개발이라고 한 이유는?

개발

소프트웨어 개발을 어떤 단계(분석 부터 배포에 이르는)에 따라 나누는 과거의 사고방식은 약화됨.

 

주도

테스트 우선 프로그래밍 test-first programming

대부분 명세기반 프로그래밍 후 테스트를 진행하므로 그와 반대되는 개념임.

 

테스트

자동화되고 구체적인며 명확한 테스트를 말함.

TDD는 테스트 기술이 아니며,

분석 설계 기술이기도 함. 개발의 모든 활동을 구조화 하는 기술

 

TDD와 익스트림 프로그래밍의 실천법 사이에 어떤 관련이 있는가?

TDD가 XP의 나머지 부분을 어떻게 향상시키는가?

• 짝 프로그래밍 : 짝으로 일하는 것은 TDD를 강화시킴. 그 리듬 때문에 몰입할 수있으며, 지칠때 활기를 줌. 작성하게 되는 테스트는 짝 프로그래밍 과정에서 좋은 의사소통 수단이 됨.
• 활기차게 일하기 : 기운이 있을때 일을 시작해 지치면 그만할 것을 권유. 테스트 통과 시키지 못할때는 멈출수 있게 도와줌(?)
• 지속적인 통합 : 테스트는 더 자주 통합할 수 있게 해주기 때문에 훌률한 자원이 됨. 테스트 통과후 중복을 제거하는 체크인.
• 단순설계 : 테스트를 통과하기 위해 최소한의 필요한 코딩을 하고 중복제거하게되면, 요구사항에 맞는 설계를 얻음. 
• 리팩토링 : 테스트가 있다면 큰 리팩토링을 수행하더라도 시스템의 행위가 변하지 않았다는 자신감을 얻을수 있음.
• 지속적인 전달 : 고객을 혼란시키지 않으면서도 더 자주 코드를 출시할 수 있음. 자신이 관리할 수없는 자원을 팔아치우는 '일일거래'

 

다락의 도전.

TDD의 범위를 얼마나 넓힐 수있나?

 

넓힐 수없는 범위

- GUI에 대한 자동화 테스트

- 분산객체에 대한 자동화 테스트

- 데이터베이스 스키마 개발

- 외부도구가 생성한 코드나 서드파티 코드

- 언어 컴파일러나 인터프리터 등