TDD-외부 입력 대 내부 출력

응용 프로그램을 구축 차이점은 무엇이고 외부에서 대를 구축 아웃 내부 TDD를 사용은?

다음은 제가 TDD와 단위 테스트에 관해 읽은 책들입니다 :
테스트 주도 개발 : 테스트 주도 개발 사례
: 실용 가이드 : 실용 가이드 Microsoft의
고품질 PHP 프레임 워크 및 애플리케이션 개발을위한 실제 솔루션
. NET
xUnit 테스트 패턴 : 리팩토링 테스트 코드
단위 테스트 기술 : .Net
Growing Object-Oriented Software의 예제와 함께 테스트 안내 ---> 이것은 JAVA가 제 기본 언어가 아니기 때문에 실제로 이해하기 어려웠습니다. :)

대부분은 일반적으로 TDD 기본 사항과 단위 테스트에 대해 설명했지만 응용 프로그램을 구성 할 수있는 다른 방법에 대해서는 거의 언급하지 않았습니다.

내가 주목 한 또 다른 사실은이 책들 대부분이 응용 프로그램을 작성할 때 디자인 단계를 무시한다는 것입니다. 테스트 사례를 빠르게 작성하고 디자인 자체를 구현하는 데 더 중점을 둡니다.

그러나 사람들이 TDD에 접근하는 방법을 설명하는 xUnit 테스트 패턴의 단락을 발견했습니다. Outside In vs Inside Out 에는 2 개의 학교가 있습니다 .

슬프게도이 시점에서이 책은 더 자세히 설명되지 않습니다. 이 두 경우의 주요 차이점이 무엇인지 알고 싶습니다.
언제 각각을 사용해야합니까?
이해하기 쉬운 TDD 초보자에게?
각 방법의 단점은 무엇입니까?
이 주제를 구체적으로 다루는 자료가 있습니까?

Inside-Out 및 Outside-In은 매우 드문 용어이며, Classic School 및 London School에 대해 더 자주 들었습니다 .

• 인사이드 아웃 (클래식 스쿨, 상향식 ) : 컴포넌트 / 클래스 레벨 (내부)에서 시작하여 요구 사항에 테스트를 추가합니다. 코드가 리팩토링으로 인해 발전함에 따라 새로운 공동 작업자, 상호 작용 및 기타 구성 요소가 나타납니다. TDD는 디자인을 완전히 안내합니다.

• 외부 입력 (런던 학교, 하향식 (top-down) 또는 "모의 객체 TDD" 마틴 파울러와 같은 그것을 부를 것이다) : 당신이 알고있는 선행 상호 작용 및 협력자 (최고 수준에서 특히)에 대해 거기 (최상위)를 시작, 필요한 종속성을 조롱. 모든 완성 된 구성 요소를 사용하면 이전에 조롱 한 공동 작업자로 이동하여 TDD로 다시 시작하여 실제 구현을 만듭니다 (이미 사용 되었더라도 추상화 덕분에 이전에는 필요 없었습니다 ). 참고 외부-의 접근 방식에 잘 어울리는 YAGNI의 원칙.

접근 방법 중 하나만이 유일한 방법은 아닙니다 . 그들은 당신이하는 일에 따라 둘 다 자리를 차지합니다. 설계의 일부가 설계자 (또는 선재)에서 나온 대규모 엔터프라이즈 솔루션에서는 "런던 스타일"접근 방식으로 시작할 수 있습니다. 다른 한편으로, 코드가 어떻게 보일지 (또는 시스템의 다른 부분에 어떻게 적용되어야하는지) 확실하지 않은 상황에 처할 때, 저급 구성 요소로 시작하는 것이 더 쉬울 수 있습니다 더 많은 테스트, 리팩토링 및 요구 사항이 도입됨에 따라 발전합니다.

어느 쪽을 사용하든 상황에 따라 자주 사용되지 않습니다.

더 자세히 읽으 려면이 구별 (원래)이 어떻게 시작되었고 런던이 가장 적합한 이름이 아닌 이유에 대해 다소 흥미로운 토론이있는 Google 그룹 게시물 이 있습니다.

짧은 답변 : 평소와 같이 코딩 선호도와 팀 접근 방식에 따라 다릅니다 .

인사이드 아웃 코딩은 항상 작동하는 것이기 때문에 훌륭합니다. 단점은 그것이 근본적으로 다른 장소에 도착하는 데 반드시 도움이되는 것은 아니라는 것입니다. 이런 식으로 코스를 차트로 작성하기가 더 어렵습니다. 마찬가지로, 외부에서 코드를 작성 하는 것은 빠른 반복 개발의 이점을 반드시 가질 필요는 없으며 코드 구조의 깊은 부분에서 발생할 수있는 모든 기회와 패턴을 반드시 볼 필요는 없다는 단점이 있습니다.

두 가지 개발 스타일 이 모두 중요 하며 팀에 다양한 스타일을 적용하는 것이 실제로 도움이 된다고 믿었 습니다. 아이디어는 내부는 빌딩 블록을 만드는 데 유용하며 사고의 외부는 형태 구조와 방향을 제공한다는 것입니다.

내 추론의 일부는 현재 반복 개발을 장려하는 매우 인기있는 사고 학교에서 왔으며 종종 내부 개발과 동의어입니다. 나는 반복적 인 개발이 큰 믿는 당신이 너무 멀리 갈 필요가 없습니다 때. 그러나 나는 순전히 반복적 인 프로세스와는 반대로 큰 그림 사고는 특정 유형의 혁신과 덜 분명한 장소에 도달하는 데 매우 중요하다고 생각합니다. 내부와 외부를 적절히 관리하면 매우 효과적인 조합이 될 수 있습니다.

C #의 Agile Prinicples, Patterns and Practices 를 해당 목록에 추가해야 합니다. 나는 그가 왜 "C #에서"를 끝 냈는지 모르겠다. 이 책은 전혀 언어가 아니며 아마존에서 별 5 개를 얻지 못한 유일한 이유는 그의 사례 중 C #-에 실망한 사람들로부터 왔습니다.

저자는 가능하면 외부에서 코드를 작성하고 진화적인 디자인에 크게 의존해야한다고 주장하며, 나는 그의 진술에 동의합니다. 그의 추론은 기능을 추가함에 따라 디자인이 항상 발전한다는 것입니다. 기능이 추가 될 때 하위 수준의 구성 요소로 시작하면 해당 구성 요소가 원하는 작업을 수행하지 않거나 작업을 수행해야한다는 것을 알 수 있습니다. 기능을 한 클래스에서 다른 클래스로 이동할 때마다 모든 단위 테스트 프로젝트에서 동일한 이동을 수행해야하는 경우 특히 비용이 많이들 수 있습니다.

반면에 애플리케이션이 무엇을 먼저해야하는지 결정하면 외부 인터페이스를 코딩합니다. 기능이 추가되고 테스트중인 코드의 크기가 커짐에 따라 애플리케이션을 더 많은 클래스로 리팩토링하지만이 리팩토링 노력이 진행되는 동안 작성한 원래 단위 테스트는 계속 유효합니다. 따라서 외부에서 완전히 시작하여 점점 더 낮은 수준의 클래스로 리팩토링을 계속하면서 내부 테스트에 추가 단위 테스트를 추가하지만 단위 테스트를 다시 작성하거나 다시 작성해야하는 경우는 거의 없습니다.

그러나 응용 프로그램에 필요한 특정 하위 수준 하위 시스템을 식별 한 경우 (그리고 회사에 이미 다른 응용 프로그램에서 해당 하위 시스템이 필요한 경우) 하위 수준의 빌딩 블록부터 시작해야합니다. 그 위에 앱을 빌드하십시오.

보시다시피, 외부 개발 (Outside-in development) 개념은 실제로 2 단계로 퍼져 있습니다. 제라드 메스 자 로스 간단히 설명 "외부-에서 그들을 디자인 "과 "외부 인 / 내부 아웃 코딩 ".

• 첫 번째 수준은 조직 및 프로세스 수준입니다. 외부 디자인은 하향식 (폭포 / 테일러) 및 상향식과 반대되는 의미입니다. 외부 접근 방식을 통해 최종 사용자의 관점에 중점을 둡니다. 스토리 테스트, ATDD 또는 BDD 테스트로 시작하여 기술 테스트 및 코드를 추론하는 "내부"로 진행합니다. 따라서 외부 디자인은 일반적으로 애자일 컨텍스트에서 수행하는 작업입니다. 댄 노스 (Dan North)는 BDD, 하향식, 상향식 및 외부 접근 방식에 대해 큰 이야기 를합니다.

• 두 번째 수준은 기술적 인 것이며 응용 계층과 관련이 있습니다. 외부 코딩은 기본적으로 UI에서 시작하여 중앙 계층 (일반적으로 비즈니스 / 도메인 계층)으로 이동하는 것을 의미합니다. 중앙 레이어에서 시작하여 외부 레이어를 마지막으로 코딩하는 내부 코딩과 반대입니다.

따라서 외부 코딩 또는 내부 코딩으로 외부 디자인을 가질 수 있습니다.

내가 Meszaros에 동의하지 않는 것은 그가 내부 테스트를 통합 테스트와 연관시킬 때이다. 내부 컨텍스트에서 "내부 소프트웨어와 별도로 외부 소프트웨어를 실제로 테스트하지는 않는다"고 주장한다. 그러나 나는 당신이 그렇게 할 수있는 것은 아무것도 없다고 생각합니다. 프로덕션 코드가 이미 존재하더라도 내부 레이어 개체를 조롱하여 외부 레이어 개체를 테스트하도록 완벽하게 선택할 수 있습니다. 인터페이스를 작성하고 조롱 한 다음 외부 코딩과 마찬가지로 나중에 구현을 작성하는 대신 기존 콘크리트 오브젝트 위에 인터페이스와 모의를 추가하기 만하면됩니다.

즉, 모의 또는 고전주의 스타일 TDD는 IMO가 외부 / 내부 코딩에 대한 직교 관심사입니다. 인사이드 아웃 접근법과 함께 모의 스타일을 완벽하게 사용할 수 있습니다. 이것의 이유는 모형 / 고전주의 스타일이 코드 의존성 에 관한 것이고 외부 / 내부 코딩은 응용 계층 에 관한 것 입니다.

또 다른 중요한 점은 종속성이 여러 계층에 국한 될뿐만 아니라 동일한 계층의 객체 사이에도 존재한다는 것입니다. 예를 들어 중앙 비즈니스 계층에서 하나의 개체로 시작하고 (내부 접근 방식) 모의 개체를 사용하여 대화하는 다른 비즈니스 계층 개체와 개체를 분리 할 수 ​​있습니다. 이것은 IoC에서 많이 발생합니다. 객체가 의존하는 추상화는 종종 동일한 레이어에서 선언되지만 구체적인 구현은 다른 레이어에 있습니다.

Robert "Uncle Bob"Martin은 내부 코딩과 간단히 " 클린 아키텍처 (Clean Architecture) " 게시물에서 분리 된 아키텍처와 어떻게 충돌하지 않는지를 언급합니다 .