tdd

그리고 private 메소드의 테스트 부분에서 생각이 나는 것이 있어서 언급을 드리면요, 대부분 private메소드가 public을 먼저 작성하다가 메소드가 추출되어서 나오기 때문에 public을 통해 자연스럽게 테스트 될 것이라는 것에 이견은 없습니다. 그런데 레가시 코드의 private 부분에서 에러가 났고 뭔가 흐름이 복잡해서 private부분만 따로 불러보고 싶을 때 이를 protected로 바꾸는 것도 가끔 해보는 기법입니다. 테스트코드가 원래 코드와 같은 패키지에서 작성되니 해당 클래스를 테스트하는 코드에서는 바로 호출이 가능하고, 필요하다면 이를 상속한 테스트용 클래스를 만들어서 해당 클래스의 일부분만이 실제 실행클래스를 사용하는 stub나 fake object를 만들수도 있습니다. 그리고 그 정도로 따로 검증이 필요한 로직이 들어간 private 메소드라면 혹시 상속한 클래스나 같은 패키지 내에서 재활용될 가능성도 있으므로 실제로 protected가 적합한 접근 범위일 가능성도 발견할 수 있구요. 뭐 이 내용은 핵심은 아니고 간단한 팁정도입니다 ^^;

 좋은 테스트의 특징: A-TRIP
1. 자동적(Automatic)
2. 철저함(Thorough)
3. 반복 가능(Repeatable)
테스트는 어떤 순서로든 여러 번 반복 실행될 수 있어야 하고, 그때마다 늘 같은 결과를 내야 한다.
이것은 테스트가 프로그래머의 직접 제어 아래 있는 않은 외부 환경에 의존해서는 안 된다는 것을 의미한다.
반복 가능성을 갖추지 않는다면, 진짜 버그가 아닌, 테스트와 관련된 문제를 찾아내기 위해 시간을 낭비해야 할지도 모른다.

독립적(Independent) 어떤 테스트도 다른 테스트에 의존하지 않고 어느 때나, 어느 순서로든, 어떤 개별 테스트라도 실행해 볼 수 있어야 한다.
전문적(Professional) 고객에게 인도하는 코드 뿐만 아니라 단위 테스트 코드도 진짜 코드다.
테스트를 테스트하기

Automated Testing Patterns and Smells

XUnit test patterns

http://parkpd.egloos.com/3174139

24페이지

3.6 Example
- Use Better Assertion- Custom assert- Replace Conditional Logic with Guard Assertion
3.12 Transaction Rollback Teardown
3.17 생성부 분리 Distinct Generated Values Creation Method

3.22 Testcase Class per Feature

3.29 Humble object Dependency Injection Dependency Lookup Test-Specific Subclass

3.30 Test Logic in Prodution code Test Double / Test Stub, Mock Object, Fake Object, Spy Object

Slow Test - 공용 Fixture setup

Lodon school vs Chicago school

http://softwareengineering.stackexchange.com/questions/123627/what-are-the-london-and-chicago-schools-of-tdd

tdd

논쟁

적용사례

시연

Kent Beck Interview

Pattern

Coverage

BDD

테스트를 위한 디자인

기법

XUnit test patterns

관련논문

Lodon school vs Chicago school