[TDD] 18장 ~ 21장

2부

xUnit이란?

이 책의 저자 켄트 백이 고안한 프레임워크인 Sunit으로부터 기능과 구조를 착안한,

unit testing framework를 통틀어 칭하는 명칭이다.

파생상품으로는 Junit, Nnuit, xUnit.net 등이 있다.

18장

xUnit으로 가는 첫걸음

2부의 주제

• TDD를 통해 실제 소프트웨어를 만드는 발전된 예제
• 자기 참조 프로그래밍에 대한 전산학 실습

이번 장에서 할 일

테스트 프레임워크를 테스트 주도 개발로 만들기.

 

• 테스트 메서드 호출하기
• 먼저 setUp 호출하기
• 나중에 tearDown 호출하기
• 테스트 메서드가 실패하더라도 tearDown 호출하기
• 여러 개의 테스트 실행하기
• 수집된 결과를 출력하기

테스트 메서드가 호출되면 true를 반환하는 원시테스트 작성

책에서는 testMethod를 정의해야 할 때 그 사실을 알아채고 스텁을 자동으로 생성해주면 얼마나 좋을까 하는데 , 코파일럿이 실제로 해준다.. 좋은 세

테스트 메서드를 직접 호출하는 대신 진짜 인터페이스인 run 메서드를 사용한다.

테스트메서드를 동적 호출

getattr 함수를 사용하면 함수를 변수에 저장할 수 있다.

현재 WasRun 클래스가 수행하는 일 두가지

• 메서드가 호출되었는지 아닌지 기억하는 일
• 메서드를 동적으로 호출하는 일

WasRun은 독립된 두가지 일을 수행하므로, TestCase 상위 클래스를 만들고 이를 상속받도록 한다.

run 메서드는 상위 클래스 속성만을 사용하므로 이 또한 상위 클래스로 옮겨주고 상속받아 사용한다.

테스트 코드를 클래스로 새로 작성한다.

테스트 메서드 호출하기

먼저 setUp 호출하기

나중에 tearDown 호출하기

테스트 메서드가 실패하더라도 tearDown 호출하기

테스트 여러 개 실행하기

수집한 결과를 출력하기

19장

테이블 차리기

테스트를 작성할 때 공통된 3A 패턴

• 준비 - 객체를 생성한다.
• 행동 - 어떤 자극을 준다.
• 확인 - 결과를 검사한다.

성능 - 여러 테스트가 같은 객체를 사용한다면, 하나만 생성해서 공유할 수 있을 것

격리 - 한 테스트에서의 성공유무가 다른 테스트에 영향을 주지 않기를 원한다.

객체를 공유하는 상태에서 하나의 테스트가 객체 상태를 변경한다면 다른 테스트 결과에 영향을 미칠 가능성이 존재.

테스트를 실행하기전 객체를 생성한 것을 확인하는 플래그를 세운다.

WasRun의 setUp을 호출해야하므로, 그 일은 TestCase에서 하도록 한다.

이렇게 할 경우 오버라이드한 setUp 함수가 실행되면서 wasSetUp 값이 설정된다.

테스트를 실행하기 전에 플래그를 검사하지 않도록 단순화한다.

각각의 테스트는 WasRun 인스턴스를 생성해서 사용하게 된다.

이번 장에서 한 일

• 테스트를 작성하는데에 간결함이 성능 향상보다 중요하다 생각하기
• setUp()을 테스트하고 구현하기
• 예제 TC를 단순화하기 위해 setUp 사용
• 예제 TC에 대한 TC를 단순화하기 위해 setUp 사용. ?

테스트 메서드 호출하기

먼저 setUp 호출하기

나중에 tearDown 호출하기

테스트 메서드가 실패하더라도 tearDown 호출하기

테스트 여러 개 실행하기

수집한 결과를 출력하기

20장

setUp은 tc가 실행되기 전에 호출되어야 하고,

tearDown은 tc가 실행된 후에 호출되어야 한다.

항상 로그의 끝부분에만 기록을 추가하면 메서드 호출 순서를 알 수 있을 것.

testSetUp 메서드가 플래그 대신 로그를 검사하도록 변경 → wasSetUp 플래그를 지울 수 있어졌다.

이 테스트가 두개의 테스트가 할일을 모두 수행하므로 testRunning을 지우고 testSetUp의 이름을 바꿔준다.

wasRun의 인스턴스를 한곳에서만 사용하므로 다시 분리했던 setUp을 합친다

테스트 메서드 호출하기

먼저 setUp 호출하기

나중에 tearDown 호출하기

테스트 메서드가 실패하더라도 tearDown 호출하기

테스트 여러 개 실행하기

수집한 결과를 출력하기

WasRun에 로그 문자열 남기기

 

이제 tearDown()을 구현..이 아닌 테스트를 해보자.

test앞에 self 를 붙인거랑 뭐가달라지는거지

실패한다. 다음과 같이 수정하자.

지금까지 한일

• 플래그에서 로그로 테스트 전략을 구조 조정
• 새로운 로그 기능을 이용하여 tearDown()을 테스트하고 구현
• 문제를 발견하고 뒤로 돌아가는 대신 수정

21장

다음으로 구현할 테스트를 선택할때 기준

→ 나에게 뭔가 가르침을 줄 수 있고

→내가 만들 수 있다는 확신이 드는 것

 

우선 TestCase.run()이

테스트 하나의 실행 결과를 기록하는 TestResult ‘객체’를 반환하게 한다.

TestResult 객체를 가짜구현으로 만들어준다.

그리고 run이 실행될때, TestResult를 결과로 반환한다.

TestResult는 실제 실행된 테스트 수를 계산한다.

이제 run함수에서 이 메서드를 실제로 호출하게 만들자.

실패하는 테스트의 수도 변수로 바꾸기 전에, 해당 개수를 측정하는 테스트를 다시 한 번 TestCaseTest에 작성한다.

 

그리고 testBrokenMethod를 구현한다.

예외 처리는 잠시 할 일 목록에 남겨두자.

 

지금까지 한 일

• 테스트 메서드 호출하기
• 먼저 setUp 호출하기
• 나중에 tearDown 호출하기
• 테스트 메서드가 실패하더라도 tearDown 호출하기
• 테스트 여러 개 실행하기
• 수집한 결과를 출력하기
• WasRun에 로그 문자열 남기기

 

이번 장에서 우리가 한 일

• 가짜 구현을 한 뒤 상수를 변수로 단계적으로 바꾸어 실제 구현으로 만들었다.
• 또 다른 테스트를 작성했다.
• 테스트가 실패할 경우 작은 스케일로 또 다른 테스트를 만들어 실패한 테스트를 성공하게 만드는 것을 보조한다.