테스트 주도 개발 - TDD 마스터 하기

32장. TDD 마스터 하기

 

단계가 얼마나 커야 하나?

 

각 테스트가 다뤼야 할 범위는 얼마나 넓은가?

리팩토링을 하면서 얼마나 많은 중간 단계를 거쳐야 하는가?

 

리펙토링 초기에는 작은 단위 부터 작업할 준비가 되어야 하며, 나중에는 단계를 뛰어 넘거나 툴을 사용해서 진행하라.

 

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

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

 

아래 목록을 테스트 하도록 하자

 

조건문

반복문

연산자

다형성

 

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

다음은 설계 문제가 있음을 알려주는 테스트의 속성이다.

 

긴 셋업 코드 : 하나의 단순한 단언을 수행하기 위해 수백 줄의 객체새성 코드가 필요하다면 뭔가 문제가 있는 거다. 객체가 너무 크다는 뜻이므로 나뉠 필요가 있다.

 

셋업 중복 : 공통의 셋업 코드를 넣어 둘 공통의 장소를 찾기 힘들다면, 서로 밀접하게 엉킨 객체들이 너무 많다는 뜻이다.

 

실행시간이 오래 걸리는 테스트 : 실행시간이 오래 걸리면 테스트를 자주 실행하지 않게 되고, 한동안 실행이 안된 채로 남게 되면 테스트가 동작을 안할 수도 있다. 그리고 테스트 시간이 너무 길다는 것은 설계에 문제가 있다는 것이므로 설계를 변경해야 한다.

 

깨지기 쉬운 테스트 : 테스트간 연결을 끊거나 두부분을 합하는 것을 통해 멀리 떨어진 것의 영향력이 없어지도록 설계해야 한다.

 

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

 

개방-폐쇄 원칙(객체는 사용에 대해서는 열려 있어야 하고, 향후 수정에 대해서는 닫혀 있어야 한다) 테스트 주도 개발은 비록 발생하지 않는 변주 종류는 잘 표현하지 못할지라도. 발생하는 변주 종듀들, 바로 그것들을 잘 표현한느 프레임워크를 만들게 해 준다.

 

그래서 3년 후에 일반적이지 않는 변화가 발생하면 이때 따른 비용이 크지 않다. 왜냐 하면 수많은 테스트 코드 들이 있기 때문이다.

 

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

 

테스트를 얼마나 작성해야 하나? 작은 예제를 풀어보자.

 

정삼각형이면 1

이등변삼각형이면 2

부등변삼격형이면 3

 

그리고 제대로 된 삼각형이 아니면 예외를 던진다.

 

저자는 실패간 평균시간(MTBF, Mean Time Between Failures)을 생각한다고 한다. 결국 실패간 평균시간이 낮은 것 에러가 빈번하게 발생하는 테스트를 우선 적으로 작성한다는 의미 같다.

 

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

 

테스트를 삭제할 경우 자심감이 줄어즐 것 같으면 절대 지우지 말아야 한다.

 

두 개의 테스트가 코드의 동일한 부분을 실행 하더라고, 이 둘이 서로 다른 시나리오를 말한다면 그대로 남겨두아야 한다.

 

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

 

TDD 주기(테스트/컴파일/실행/리팩토링)를 수행하기 힘든 언어나 환경에서 작업하게 되면 단계가 커기는 경향이 있다.

 

각 테스트가 더 많은 부분을 포함하게 만든다.

중간 단계를 덜  거치고 리팩토링을 한다.

 

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

책에서는 결론적으로 큰 시스템도 TDD 로 개방이 가능 하다고 예시를 들고 있음

 

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

 

기술적 문제 : 고정물을 만드는것이 어렵다. 아직 만들지 않은 기능에 대한 테스트를 어찌 작성하고 실행 할지 불 명확하다. 이때 우아한(?) 에러를 밷는 해석기를 도입하는 것이 방법이 될 수있다고 한다(?)

 

애플리케이션 테스트 주도 개발에서는 사회적인 문제도 존재한다. 구현하기 전에 조직에서 책을 가져야하는 문제가 있고, 애플리케이션 테스르를 우선적으로 작성하기 위해서는 협조 노력이 필요하다.

 

ATDD의 또 다른 문제는 테스트와 피드백 사이의 길이다. 

 

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

일반적으로 TDD가 적용되지 않은 프로젝트를 바꾸는 것은 어렵다. 테스트를 염두에 두지 않고 만든 코드는 테스트하기가 그리 쉽지 않다. 일부만을 격리해서 실행하고 결과를 검사할 수 있게끔 설계되어 있지 않다.

 

확실히 하지 말아야 할 것은 코드 전체를 위한 테스트를 한꺼번에 다 만들고, 코드 전체를 한번에 리팩토링 하는 일이다. 

 

우선, 변경 범위를 제한해야 한다.

 

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

 

TDD는 누구를 위한 것인가?

결론은 구조를 깔끔하고 우아하게 가지고 가고 싶은 개발자(?)

TDD는 시간이 지남에 따라 코드에 대한 자심감을 쌓아갈 수 있게 해준다. 설계를 개선해 나감에 따라 점점 더 많은 설계 변경이 가능해 진다. 

 

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

(?)

 

TDD와 패턴의 관계는?

예를 들어 스트래티지 패턴을 사용하기로 결정했다고 치자. 첫 번째 변화를 위한 테스트를 작성하고 이를 메서드로 구현한다. 그 다음 리팩토링 단계에서 자연스럽게 스트래티지 패던이 나타날 수 있도록 하기 위해 의식적으로 두번째 테스를 작성한다. 결국 TDD와 패턴은 연관이 있다.

 

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

결함을 빨리 발견해 고칠수록 비용은 낮아진다. 결론은 TDD를 통해 코드와 설계의 신뢰 더 나아가 고객의 신뢰 까지 얻는 다는 것이다. 

TDD의 또 다른 효과는 설계 결정에 대한 피드백 고리를 단축시킨다는 것이다. 

 

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

개발 : 의사결정에 시차가 있으면 그 사이에 피드백이 어렵기 때문에, 소프트웨어 개발을 어떤 단계에 따라 나누는 과거의 사고 방식은 약화 되었다. 여기서 개발이란 분석,논리적 설계, 물리적 설계, 구현, 테스팅, 검토, 통합, 배포를 아우르는 복잡한 춤을 말한다.

 

주도 : 개발 주도의 주최가 테스트

 

테스트 : 자동화되고 구체적이며 명확한 테스트를 말한다.

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

• 짝프로그래밍
• 활기차게 일하기
• 지속적인 통합
• 단순 설계
• 리팩토링
• 지속적인 전달