프로그래머는 자기 작업의 품질에 대해 우선적으로 책임을 질 수 있어야 한다.
테스트 주도 개발은 책임을 맡는 방법이다. 테스트 주도 개발은 테스트라는 매커니즘을 통해 프로그래밍을 하며 생기는 두려움을 방지해 행동하고, 커뮤니케이션하게 한다.(용기)
이 책을 통해
- 작업을 단순하게 시작하고
- 자동화된 테스트를 만들고
- 새로운 설계 결정을 하나씩 도입하는 리팩토링이 가능하다
테스트 주도 개발의 목표
“작동하는 깔끔한 코드(clean code that works)” - 론 제프리즈(Ron Jeffries)
테스트 주도 개발의 규칙
- 자동화된 테스트가 실패할 경우에만 코드를 수정한다
- 중복을 제거한다
테스트 주도 개발 CYCLE
- 빨강 🔴 - 실패하는 테스트를 만든다
- 초록 🟢 - 테스트를 통과하게끔 만든다
- 리팩토링 - 테스트만 통과하게 만드는중에 생겨난 중복을 제거한다
- 리팩토링이란? 코드의 외적 행위는 그대로 유지하면서 내부 구조를 변경하는 작업
예제는 아래와 같은 과정을 통해 진행되었다
- 작업해야할 테스트 목록을 만든다
- 외부에서 오퍼레이션이 어떻게 보일지 코드로 표현한다
- 테스트를 작성할 때는 오퍼레이션의 인터페이스를 먼저 생각해보는것이 좋다
- 스텁 구현을 통해 테스트를 컴파일한다.
- 스텁 구현(stub implementation)이란? 메서드의 서명부와 반환 명령만 적는 식으로 메소드를 호출하는 부분의 컴파일을 위한 껍데기
- 테스트를 통과하게 코드를 일부 변경한다
- 이 과정에서 끔찍한 죄악을 저지를 수도 있다고 한다
- 단순히 돌아가는 코드를 작은 단계로 점진적으로 일반화한다
- 작은 단계로 구현할 수 있는 능력을 갖추자
테스트를 통과시키는 세 가지 전략
가짜로 구현하기
먼저 상수를 반환하게 하고 단계적으로 구현하며 상수를 변수로 바꾸어 나간다
명백한 구현 사용하기
실제 구현을 입력한다.
삼각측량법(Triangulation)
여러 예제를 이용해 코드를 일반화한다
격리된 테스트
테스트의 공통된 패턴: 3A 패턴 - 빌 웨이크(Bill Wake)
- 준비(Arrange) - 객체를 생성
- 행동(Act) - 어떤 자극을 준다
- 확인(Assert) - 결과를 검사
1의 객체 생성은 여러 테스트에서 동일하게 사용할 수 있다. 그렇다면 매번 새로 생성하지 않고 재활용해도 될까?
이 문제에서는 두가지 제약이 상충한다.
- 성능 차원 - 같은 객체를 사용하면 빨리 실행될 수 있다.
- 격리 차원 - 한 테스트의 성공이나 실패가 다른 테스트에 영향을 주지 않기를 원한다. 만약 하나의 테스트가 객체의 상태를 변경한다면 다음 테스트의 결과에 영향을 미칠 수도 있다.
결론은 테스트 사이의 커플링을 만들지 말자. 테스트 사이에 순서 또는 한 테스트의 결과가 다른 테스트의 결과에 영향을 미칠 경우, 한 테스트가 깨지면 다른 테스트들은 올바르더라도 깨지거나 최악의 경우 잘못된 테스트가 통과하는 안좋은 상황이 발생할 수 있다.
테스트를 커플링 없이 작은 스케일로 격리하기 위해서, 시스템은 응집도가 높고 결합도는 낮은 객체 모음으로 구성되게 만들어야 한다.
‘테스트할 시간이 없다’ 나선을 탈출
위의 양성 피드백 고리(positive feedback loop)에 의해 스트레스를 많이 받으면 테스트를 점점 더 뜸하게 할것이고, 테스트를 뜸하게 하면 에러는 점점 더 많아질 것이다. 에러가 많아지면 스트레스를 받는다.
이 고리에서 빠져나오기 위해서는 기존 요소와 바꿔치기를 하거나, 화살표를 바꾸면 된다.
테스트 자동화
기존 ‘테스트’를 ‘자동화된 테스트’로 치환한다. 자동화 테스트는 스트레스를 받는 상황에서 초록 막대로 안정감을 준다. 에러를 낼 일도 줄어들게 되고, 스트레스도 적어진다.
테스트 우선
위쪽에 있는 스트레스와 아래에 있는 테스트의 위치를 바꾸는 것이다. 테스트를 먼저 하면 화살표 아래 스트레스가 음성으로 연결되고, 테스트를 더 많이 하게 된다.
Comments powered by Disqus.