BizTalk에서 DDD, TDD를 어떻게 계속 사용할 수 있습니까?

Question

저는 직장에서 BizTalk에 착수하기 시작했고 DDD, TDD 등에 대해 배운 모든 것을 계속 사용하고 싶습니다. 파이프 라인과 같은 것을 만들 때 편집자와 같은 Visio를 항상 사용해야 할 수도 있습니다. 오케스트레이션?

Answer 1

확실히 TDD 및 DDD 개념을 BizTalk 개발에 적용 할 수 있습니다.

도메인 개체의 개념을 중심으로 디자인하고 개발할 수 있습니다.하지만 BizTalk 및 통합 개발에서는 인터페이스 개체를 자주 찾거나 처음 생각한 디자인이 더 유용합니다. 즉, 내 인터페이스에서 전달되는 메시지입니다. 또한 '가능한 가장 간단한 작업 만들기'및 'TDD의 테스트 통과 철학 만들기'를 수행 할 수도 있습니다.

그러나 이러한 디자인 및 개발 방식의 코드 중심 측면에 대해 더 자세히 묻고 싶습니다.

요구 사항을 수행하고 실패한 테스트를 먼저 작성한 다음 요구 사항을 충족하고 테스트를 통과시키는 테스트 개발 개발 방식을 따르고 싶습니다. C#과 같은 전통적인 프로그래밍 언어 내에서?

불행히도 대답은 '아니오'입니다. 대부분의 BizTalk 아티팩트 (파이프 라인, 맵, 오케스트레이션 ...)는 Visual Studio BizTalk 플러그인을 사용하여 실제로 빌드 할 수 있습니다. 근본적인 C# 코드를 보는 방법이 있지만이 코드를 직접 개발하고 직접 개발하려고하지는 않습니다.

BizUnit 및 BizUnit Extensions은 BizTalk 응용 프로그램의 실행을 제어하고 테스트 할 수있는 몇 가지 기능을 제공하지만 실제로는보다 제어되고 테스트 중심의 통합 테스트를 수행 할 수 있습니다.

오케스트레이션 디자인 화면으로 끌어서 놓는 모양은 대부분 한 가지 불투명 한 실행 단위로 작동합니다. 오케스트레이션, 파이프 라인,지도 등은 모든 BizTalk 솔루션 내에서 실행되고 테스트됩니다.

TDD와 같은 접근법에서 나온 포인터를 사용하면 BizTalk 솔루션이 더 작고 모듈화되어 있고 테스트 할 수있는 덩어리가 될 수 있으며 파이프 라인 같은 것들을 개별적으로 테스트 할 수있는 방법이 있습니다.

그러나 코드에서 TDD 및 DDD의 세부 사항은 슬프게도 번역되지 않습니다.

Mocking WebService consumed by a Biztalk Request-Response port

Answer 2

당신은 (기능 시나리오) 만들고 모두 코드에서 일반적인 테스트 케이스를 재사용하고 엑셀 BizUnit를 사용할 수

: 도움이 될 수있는 몇 가지 관련 논의는

이 질문을 참조 http://www.codeplex.com/bizunit

BizTalk Server 2009에는 IDE 통합 테스트 가능성이 더 높을 것으로 예상됩니다.

건배 헤밀.

Answer 3

BizTalk에서 파이프 라인과 사용자 지정 파이프 라인 구성 요소를 자주 사용하는 경우 내 자신의 PipelineTesting 라이브러리가 유용 할 수 있습니다.NUnit (또는 원하는 다른 테스트 프레임 워크)을 사용하여 완전한 파이프 라인, 특정 파이프 라인 구성 요소 또는 스키마 (예 : 플랫 파일 스키마)에 대한 자동화 된 테스트를 만들 수 있습니다.

이런 종류의 기능을 사용하면 매우 유용합니다. 내 스스로 그렇게 말할 수 있다면 (제 자신의 프로젝트에서 많이 사용합니다).

here 라이브러리에 대한 소개 및 github에 대한 전체 코드를 찾을 수 있습니다. 또한 wiki에 대한 자세한 문서가 있습니다.

Answer 4

BizUnit은 모든 테스트가 프로그래밍 언어 대신 XML로 작성되므로 실제로 사용하기가 쉽지 않습니다.

우리 프로젝트에서는 BizUnit의 일부를 일반 오래된 C# 테스트 프레임 워크로 "이식"했습니다. 이를 통해 BizUnit의 C# NUnit/MSTest 코드 단계 라이브러리를 직접 사용할 수 있습니다. 따라서 테스트가 실패 할 경우 디버깅하기 쉽고 (VS Intellisense를 사용하여) 작성하기 쉽고, 유연성이 뛰어나며, 가장 중요합니다. 이 접근법의 가장 큰 단점은 BizUnit의 주요 소스에서 벗어났다는 것입니다.

향후 프로젝트에서 고려해야 할 또 다른 흥미로운 옵션은 BooUnit으로, BizUnit 상단의 Boo 래퍼입니다. BizUnit "포트"와 유사한 장점이 있지만 BizUnit을 사용하는 대신 BizUnit을 계속 사용하는 장점이 있습니다.

Answer 5

나는 CKarras의 의견에 동의합니다. 많은 사람들이 BizUnit 프레임 워크를 좋아하지 않는 이유라고 언급했습니다. 그러나 BizUnit 3.0을 살펴보십시오. XML 대신 C#/VB에서 전체 테스트 단계를 작성할 수있는 개체 모델이 있습니다. BizUnitExtensions가 새로운 개체 모델로 업그레이드되고 있습니다.

XML 기반 시스템의 장점은 테스트 단계를 생성하는 것이 더 쉽고 단계를 업데이트 할 때 다시 컴파일 할 필요가 없다는 것입니다. 내 자신의 Extensions 라이브러리에서 XmlPokeStep (NAnt에서 영감을 얻은)이 매우 유용하다는 것을 알았습니다. 우리 팀은 테스트 단계 xml을 즉시 업데이트 할 수있었습니다. 예를 들어 고객 레코드를 만든 웹 서비스를 호출 한 다음 동일한 레코드에 대한 데이터베이스를 검사해야한다고 가정 해 보겠습니다. 이제 webservice가 동적으로 생성 된 ID를 반환하면 우리는 다음 단계에 대한 테스트 단계를 즉시 업데이트 할 수 있습니다 (물론 동일한 XML 파일이 아닌). 그러면 데이터베이스를 확인하는 데 사용할 수 있습니다.

코딩 관점에서 인텔리전스는 이제 BizUnit 3.0에서 다루어 져야합니다. XSD가 없었기 때문에 과거에는 일이 어려워졌습니다. 인텔리 센스에서 도움이 될 XSD를 얻으려고합니다. BizUnit의 이전 버전에도 일부 스 니펫이 있었지만 업데이트되지 않았습니다.

TDD 문제로 다시 돌아 가면 TDD (의도적 또는 동작 중심적 요소)의 의도를 취하면 BizTalk가 계약 기반으로 많이 바뀌기 때문에 BizTalk 개발에 어느 정도 적용 할 수 있습니다 개발. 따라서 인터페이스를 먼저 지정하고 스텁 오케스트레이션 등을 작성하여 처리 한 다음 코어를 빌드 할 수 있습니다. 그 당시 BizUnit 테스트를 작성할 수있었습니다. 이 프로세스를 자동화 할 수있는 도구가 있었으면 좋지만 지금은 그렇지 않습니다.

ESB 지침과 같은 프레임 워크를 사용하면 시스템을 반복적으로 사용하여 주요 유스 케이스를 구현할 수 있도록 기본 플랫폼을 제공 할 수 있습니다.

몇 가지 생각. 희망이 도움이됩니다. 나는 블로깅 가치가 있다고 생각한다. 이것은 토론하기 좋은 주제입니다. 질문이 있거나 항상 더 많은 것을 토론 할 수 있다면 저에게 핑을 보내주십시오.

RGDS 벤지