TDD의 런던 및 시카고 학교는 무엇입니까?

TDD (Test Driven Development)의 런던 스타일과 시카고 스타일 (때로는 디트로이트 스타일)에 대해 들었습니다.

유타 익스트림 프로그래밍 사용자 그룹 워크숍 :

상호 작용 스타일의 TDD도라고 모의 객체 스타일 , 또는 런던 스타일 이 인기가 어디 런던의 익스트림 화요일 클럽 후. 일반적으로 더 상태 기반 인 디트로이트 스타일 또는 클래식 TDD 와 대조됩니다 .

제이슨 고먼의 워크샵 :

이 워크샵은 시카고 TDD 학교 (국가 기반 행동 테스트 및 삼각 측량)와 런던 학교를 대상으로합니다 .이 학교 는 상호 작용 테스트, 조롱 및 엔드 투 엔드 TDD에 더욱 중점을두고 책임 중심의 설계 및 Steve Freeman과 Nat Pryce의 뛰어난 Growing Object-Oriented Software Guided By Tests 책에 의해 최근에 다시 채워진 OO 에 대한 접근 방식을 말하지 마십시오 .

포스트 클래식 TDD 또는 "런던 스쿨"? Jason Gorman은 도움이되었지만 그의 예제는 두 가지 접근 방식을 가진 하나의 예제 대신 두 개의 다른 예제를 사용하기 때문에 나를 혼란스럽게했습니다. 차이점은 무엇입니까? 각 스타일을 언제 사용합니까?

"계산기"라는 클래스가 있고 "계산기"를 사용하여 "계산"에 전달 된 인수에 따라 다른 유형의 계산을 수행하는 "계산"이라는 메소드가 있다고 가정합니다 (예 : "multiply (x, y)"또는 "subtract ( x, y) ".

이제 ledger.calculate ( "5 * 7")를 호출 할 때 발생하는 상황을 테스트하려고한다고 가정하십시오.

London / Interaction 학교에서는 Calculator.multiply (5,7)가 호출되었는지 여부를 확인하도록합니다. 다양한 조롱 프레임 워크가이 기능에 유용하며, 예를 들어 "계산기"개체의 소유권이없는 경우 (직접 테스트 할 수없는 외부 구성 요소 또는 서비스 인 경우) 유용합니다. 특정 방식으로 전화해야한다는 것을 알고 있습니다).

시카고 / 주립 학교는 결과가 35인지 여부를 주장 할 것입니다. jUnit / nUnit 프레임 워크는 일반적으로이를 수행하는 데 적합합니다.

둘 다 유효하고 중요한 시험입니다.

Martin Fowler의 Mocks Are n't Stubs 기사 는이 주제에 대한 좋은 소개입니다.

선택한 디자인 스타일 (및 프로그램을 작성하는 디자인 원칙)에 따라 최소한 두 가지 방법으로 객체를 볼 수 있습니다.

1. 입력을 기반으로 계산을 수행하는 단위입니다. 이 계산의 결과로 객체는 값을 반환하거나 상태를 변경할 수 있습니다.
2. 메시지 전달을 통해 시스템의 다른 요소와 통신하는 활성 요소입니다.

첫 번째 경우, 처리 결과 또는 처리 후 오브젝트가 남아있는 상태에 관심이 있습니다. 여기 assertEquals()에 그림 과 같은 방법이 입력됩니다. 이 경우 처리에 관련된 다른 개체, 호출 된 메서드 등은 중요하지 않습니다. 이러한 종류의 확인을 상태 기반 확인이라고하며 "클래식"스타일입니다.

두 번째 경우, 대부분의 객체는 결과를 반환하지 않기 때문에 (예 : voidJava의 메소드), 객체가 서로 통신하는 방법 및 테스트에 의해 부과 된 상황에서 올바른 메시지를 전달하는지에 더 관심이 있습니다. 이러한 상호 작용은 일반적으로 모의 프레임 워크를 통해 확인됩니다. 이러한 종류의 검증을 행동 기반 또는 상호 작용 기반 검증이라고합니다. 그 의미 중 하나는 Behavior Driven Development라는 기술로, 공동 작업자가 아직 존재하지 않더라도 이미 존재한다고 가정하여 클래스를 개발함으로써 인터페이스에 대해 코딩 할 수 있습니다.

이것은 하나의 선택이 아닙니다. 두 가지 접근 방식을 혼합하여 각각을 최대한 활용하는 디자인 스타일을 가질 수 있습니다.