TDD[2]

XUnit 예시

XUnit은 직접 해보지 않고 책만 읽음

XUint 으로 가는 첫 걸음

정리

1. 자기 과신에 차서 몇 번의 잘못된 출발을 한 후, 아주 자그마한 단계로 시작하는 법을 알아냈다.
2. 일단 하드코딩을 한 다음에 상수를 변수로 대처하여 일반성을 이끌어 내는 방식으로 기능을 구현
3. 플러거블 셀렉터를 사용했다. 플러거블 셀렉터는 정적 코드 분석을 어렵게 만들기 때문에 앞으로 최소 4개월 안에는 사용하지 않기로 약속
   • 메서드 이름을 저장하여 해당하는 메서드를 동적으로 호출하는 방법
4. 테스트 프레임워크를 작은 단계로만 부트스트랩했다.

테이블 차리기

테스트를 작성하면 공통된 패턴을 발견하게 된다. 3A 패턴 given - when - then 아닌가?

1. 준비 (arrange) - 객체를 생성
2. 행동 (act) - 어떤 자극을 준다
3. 확인 (assert) - 결과를 검사한다.

정리

1. 테스트를 작성하는데 성능 보다는 간결함이 우선이다.
2. 중복된 코드는 픽스처를 통해 단순화할 수 있다.

뒷정리하기

픽스처로 외부 자원을 할당할 경우 테스트 종료 시 꼭 반환을 해주어야 한다

정리

1. 플래그에서 로그로 테스트 전략 구조를 조정했다.
2. 새로운 로그 기능을 이용하여 tearDown()을 테스트하고 구현했다. AfterEach
3. 문제를 발견했지만 뒤로 돌아가는 대신 수정을 했다(옳은 선택일지??)

셈하기

테스트는 순서가 중요하다 만약 하나의 테스트가 성공했음에도 그 다음 테스트를 만들며 문제가 생긴다면 두 단계 뒤로 물러서는 것을 고려한다.

정리

1. 테스트가 실패한 경우 좀더 작은 스케일로 또 다른 테스트를 만들어서 실패한 테스트가 성공하도록 보조할 수 있다.

실패 처리하기

실패한 테스트가 존재하다면 좀더 세밀한 테스트 작성으로 올바른 결과를 출력하는걸 확인하자.

정리

우리는

1. 작은 스타일의 테스트가 통과하게 만들었다.
2. 큰 스케일의 테스트를 다시 도입했다.
3. 작은 스케일의 테스트에서 보았던 메커니즘을 이용하여 큰 스케일의 테스트를 빠르게 통과시켰다.
4. 중요한 문제를 발견했는데 바로 처리하기 보다는 할일 목록에 적어두었다.

얼마나 달콤한지

정리

1. testsuite를 위한 test 작성
2. 공통된 셋업 코드를 분리

xUnit 회고

xUnit을 직접 구현해볼 이유

숙달 : xUnit의 정신은 간결함에 있다. 그러나 몇몇 구현은 조금 복잡해 보인다.
      직접 만들어 사용하면 숙달된 도구를 쓰는 느낌을 받게된다.
탐험 : 처음 언어를 접할 때 해당 언어로 xUnit을 이용해 제작해보자.
      테스트가 8~10 정도 통과하게 될 경우 프로그래밍 하면서 접하게 될 많은 기능을 한 번씩 경험해보게 될 것 이다.

• xUnit을 사용하면 단언(assertion)의 실패와 나머지 종류의 에러 사이에 큰 차이점이 있음을 알게 될 것이다. 일반적으로 단언 실패가 디버깅 시간을 더 많이 잡아먹곤 한다.
• JUnit은 간단한 테스트 인터페이스를 선언하는데 TestCase와 TestSuite 모두 이를 상속받는다. 만약 JUnit 도구가 여러분의 테스트를 실행하게 만들고 싶다면 테스트 인터페이스를 구현하며 된다.
  • 동적 타이핑 언어에서는 인터페이스에 대한 충성을 선언할 필요도 없으며, 그냥 해당 오퍼레이션을 구현하면 된다.