조롱하는 웹 서비스에서 소비 Biztalk 요청-응답 포트

https://stackoverflow.com/questions/256897

05-07-2019
|

문제

내가 사용하는 BizUnit 하는 장치-테스트 내 Biztalk 오케스트레이션이지만,일부 오케스트레이션이 소비하는 웹 서비스,그리고 이러한 테스트와 같은 더 많은 것 같다 통합 테스트보다 단위 테스트입니다.

나는 익숙을 사용하여 조롱하는 프레임워크를 모의 생성되는 프록시는 개체를 테스트하기 위해서는 웹 서비스에서는 윈도우 폼 응용 프로그램지만,나는 그것을 할 수 있는 더 통합 방식에서 요청-응답 포트?

당신은 어떻게 접근 방식이 문제입니까?

해결책

이것은 Biztalk 개발자로서 나의 주요 자극 중 하나의 핵심으로갑니다. Biztalk는 단위 테스트에 자체적으로 빌려주지 않습니다. 인터페이스의 99%가 Biztalk 응용 프로그램으로의 99%가 메시지를 기반으로하고 오케스트레이션의 불투명 한 특성을 통해 수많은 입력을 가지고 있습니다. Biztalk는 기능 단위를 테스트하는 실질적인 방법을 제공하지 않습니다. 단위.

Biztalk의 경우 통합 테스트는 슬프게도 종종 도시에서 유일한 게임입니다.

이로 인해 Kevin Smith의 결함이 없어서 Bizunit (IMO)가 잘못되었습니다. 더 나은 이름은 아마도 기생충 일 것입니다. Bizunit은 통합 테스트를 지원하는 다양한 도구를 제공합니다. 파일이 주어진 디렉토리에 작성되었는지 확인하거나 HTTPRequest를 Biztalk httpreceive 위치로 전송하는 것과 같은 대부분의 테스트를 제공합니다.

이제 내가 그 소리를 냈기 때문에, 당신이 요구하는 것은 내가 오랫동안 생각해 왔던 것입니다.지도를 작은 변화로 만들었다는 확신을주는 자동화 된 단위 테스트를 만들 수있는 능력입니다. 'T는 갑자기 다른 다운 스트림을 깨고 외부 서비스에 대한 의존성을 제거하는 방법입니다.

나는 이것을하는 좋은 방법을 생각한 적이 없지만 아래는 솔루션입니다. ~해야 한다 작업, 나는 이것의 각 부분의 변형을 분리하여 수행했지만 결코 시도하지는 않았지만이 특정 형태로 모두 함께 노력하지 않았습니다.

따라서 실제로 외부 호출을 할 필요없이 외부 서비스 (아직 존재하지 않을 수도 있음)에 대한 전화를 조롱하려는 욕구를 감안할 때 그리고 해당 서비스 호출에 대한 기대치를 설정하고 응답의 특성을 지정할 수있는 능력을 갖기를 원하면, 내가 생각할 수있는 유일한 방법은 사용자 정의 어댑터를 개발하는 것입니다.

사용자 정의 어댑터를 사용하는 모의 웹 서비스

사용자 정의 요청-응답 어댑터를 구축하면 SOAP 어댑터 대신 보내기 포트에 연결할 수 있습니다. 그런 다음 웹 서비스의 모의 역할을 할 수있는 어댑터의 속성을 지정할 수 있습니다. 어댑터는 개념이 루프백 어댑터와 유사하지만 내부 조롱 로직을 허용합니다.

어댑터 속성으로 포함시킬 수있는 것 :

예상 문서 (아마도 Biztalk Applicaiton이 웹 서비스로 전송 할 것으로 예상되는 예를 지정하는 디스크 위치).
응답 문서 - 어댑터가 메시징 엔진으로 다시 보낼 문서.
문서 요소의 조회 값과 같은 테스트에 대한 구체적인 기대.

또한 사용자 정의 어댑터가 디스크에 쓰기를 작성하고 Bizunit 단계를 설정하여 작성된 파일을 검증 할 수도 있습니다.

커스텀 어댑터를 구축하는 것은 사소한 일이지만 가능하면 가능하면 Biztalk 어댑터 마법사 사용자 정의 어댑터 배포에 관한 기사가 있습니다 여기.

마법사가 생성 한 코드에 버그가 있으므로 변경해야합니다. new Guid(""), 에게 new Guid().

Biztalk SDK에 맞춤 어댑터를 구축하는 몇 가지 예가 있습니다.

또 다른 옵션은 일반 HTTP 페이지와 논의 된대로 HTTP 요청 응답을 사용하는 것입니다. 여기, 모든 논리는 HTTP 페이지에 들어갑니다. HTTP 호출을받는 것이 행복하고 테스트를 듣기 위해 IIS 포트를 설정하는 경우 이는 더 간단 할 수 있습니다.

초기화 단위 테스트

.BAT 파일을 사용하여 바인딩 파일을 BizTalk 응용 프로그램으로 가져올 수 있습니다.

실행하는 각 테스트에 대한 새 바인딩 파일과 표준 응용 프로그램 설정에 대해 적절한 배치 파일을 실행하여 올바른 바인딩을 적용 할 수 있습니다.

각 바인딩 파일은 Mock 사용자 정의 어댑터를 사용하여 해당 테스트의 특정 속성을 설정하도록 웹 서비스 Sendport를 변경합니다.

그런 다음 테스트 단계의 설정을 기반으로 (아마도) 바인딩 설정을 생성 한 다음 쉘 명령을 실행하여 바인딩을 업데이트하는 사용자 정의 기생충 단계를 만들 수도 있습니다.

메시지 내용 테스트

당신이 고려하고 싶은 마지막 것은이 모든 것을 실제로 묶는 것은 메시지의 내용을 테스트하는 방법입니다. 모의 어댑터 에서이 작업을 수행 할 수 있지만 큰 메시지 나 가능한 다양한 입력 메시지에 대해 매우 빠르게 지루해집니다.

한 가지 옵션은 호출하는 사용자 정의 파이프 라인을 만드는 것입니다. 스키드론 수신 한 파일을 검증합니다. Schematron은 XSD를 훨씬 더 풍부한 수준의 파일 검사를 허용하는 스키마 언어이므로 "요소 X 에이 컨텐츠가 포함되어 있으면 요소 Y가 존재할 것으로 예상됩니다"와 같은 것을 확인할 수 있습니다.

Schematron 스키마를 매개 변수로 취한 사용자 정의 파이프 라인을 구축 한 경우 특정 단위 테스트를 위해 테스트 파일을 교체 하여이 테스트의 경우 웹 서비스를 호출 할 때 실제로 원하는 파일이 일치하는 파일을 얻을 수 있습니다. (그리고 XSD와 일치하지 않습니다)

다른 팁

공동 저자로의 BizUnitExtensions(www.codeplex.com/bizunitextensions 다)나는 것에 동의는 이름이"단위에서"BizUnit 복잡할 수 있지만 Biztalk 의'통합 테스트는'유닛 테스트입니다.일부 Biztalk 민속가 성공적으로 사용되는 조롱을 테스트하는 파이프라인 구성 요소와 다른 테스트 장비(+BizUnit/확장)을 테스트하는 스키마와 지도입니다.

오케스트레이션 불행하게도는 불투명하다.그리고 좋은 이유입니다.

(a)때문에 큰 구독 시스템 메시지 상자에서-그것은 오케스트레이션을 사용할 때 활성화되는 등,그것을 가능하지 않은 화재까지 일부는"가상"프로세스하는 호스트 오케스트레이션(수행 할 수 있습니다에 대한 파이프라인.토마스 레스트레포하여 무엇을 따라 이러한 선).

(b)또한,어떻게 이 가상 프로세스 처리 지속성 및 탈수?.나는 내기를 사용하는 사람들 WF 것 같은 문제에 노력하고 워크플로우를 테스트합니다.

(c)우리는 작업으로 C#직접 방법이 없습니다 그래서 우리는"주"모의 인터페이스로 오케스트레이션 코드입니다.

(d)오케스트레이션은 정말"단위".그것의 합성 요소입니다.단위는 메시지가고 메시지 상자 및 외부 구성 요소라는 표현을 통해 모양입니다.그래서 수 있는 경우에 주입하는 모의 인터페이스 웹 서비스할 수 없습니다 주입하는 모의 메시지 상자 및 상관 관계를 설정하고 다른 것들입니다.

하나 할 수 있는 일에 대한 오케스트레이션(고 고려 했습니다 추가 BizUnitExtensions 라이브러리를 이렇게)은 링크와 함께 OrchestrationProfiler 도구로는 도구를 제공합 예쁜 대한 자세한 보고서는 모든 모양이고 어떻게든 검사는 각 단계를 실행한(그리고 아마도 걸린 시간은 실행을 위해).이 갈 수있는 아주 멀리 만들기에 오케스트레이션이 더 백색 상자입니다.또한 고려하는 디버거 오케스트레이션 보여주는 많은 변수의 값을 반드시 그것에서 얻을 수 있는 정보 API 를 통해 어떤 표시하는 변수 값을 했다 주어진 시점에서 주어진 인스턴스입니다.

다시 리처드의 질문은 하지만,나 이전 dev 팀은 해결책이 있었다.기본적으로 우리는 무엇이었을 쓰는 일반 구성 httphandler 를는 구문 분석 들어오는 요청을 서비스하고 반환되는 미리 설정된 응답합니다.응답을 보낸 뒤에 따라 구성과 같은 조건 XPath.에서 구축하고 DEV 바인딩을 파일로 웹 서비스 종료 지점이었 mock.이 일을 훌륭하게 분리 구축 및 개발 환경에서 실제 세 번째 파티 webservices.이것은 또한 도움이에서"계약"첫째로 접근 방식은 우리는 모의고 orch 개발자가 사용하는 동안 webservice 저자이 가장 실제적인 서비스입니다.

[업데이트:17-FEB-09:이 도구는 지금 codeplex: http://www.codeplex.com/mockingbird.이 재미있는 소리 접근 방식 그것을 확인하고 당신이 당신의 생각의 도구]

기 전에,지금 누군가 발생 오래된"무엇에 대해 모의 개체 프레임워크를"밤에,내가 말하는 유틸리티 상을 위해 사용되었을 모두 Biztalk'소비자뿐만 아니라 비 Biztalk 소비자,그러나 근무하고 있으로 NMock2 하에게 적용되지 않을 수 있는 훌륭한 방법을 모의 인터페이스와 기대를 설정할 때 쓰는 CLR 소비자 있습니다.(나가 될 것으로 보고 MoQ 및 TypeMock 등 곧).그러나,그것은 작업으로 오케스트레이션을 위해 위에서 설명한 이유.

이게 도움이 되었으면 좋겠습니다.

감사합니다,

Benjy

하지 않습니다.

지에 대해 테스트 임의 인터페이스 및 생성하지 않을 조롱한다.

대부분의 사람들을 볼 것 같 개발자(단위)테스트로 테스트하기위한 목적으로 사소,개인 단위의와 같은 기능을 하나의 클래스입니다.다른 한편으로,그것은 또한 중요한를 수행하는 고객(수용/통합)테스트의 주요 하위 시스템 또는 전체 시스템입니다.

웹 서비스에 대해,이 사소의 단위 기능은 숨겨진 클래스에서 실제로 수행하는 의미있는 서비스,통신 뒤에 배선입니다.해당 클래스가 있어야 개인 개발자 테스트 클래스를 확인하는 자신의 기능을 완전히 없이 웹 서비스 중심의 커뮤니케이션 배선입니다.자연적으로,그러나 어쩌면 분명하지 않는다는 것을 의미하는 당신의 구현의 기능을 분리되어야에서의 구현은 배선입니다.그래서,당신의 개발자(단위)테스트코의 특별한 배선 통신;일부인의 통합 볼 수 있습니다(적절하게)으로"프리젠테이션"문제보다는"기업 논리".

고객(수용/통합)테스트를 해야 주소 훨씬 더 큰 규모의 기능을 하지만 아직에 초점을 맞추지 않"프레젠테이션"문제입니다.이것은 사용하여 외관의 패턴은 일반적인--노출 하위 시스템으로 통합한 굵은 입자,테스트 인터페이스입니다.다시,웹사 서비스 통신을 통합하는 무관과는 별도로 구현.

그러나,그것은 매우 유용한 구현에는 별도의 설정의 테스트를 실제적으로 포함하는 웹 서비스합니다.하지만 나는 강하게 추천에 대한 테스트용으로만 한쪽의 통합:테스트 end-to-end.건설하는 것을 의미합하는 테스트는 웹 서비스로 고객처럼 실제 프로덕션 코드그들은 소비하는 웹 서비스를 정확히는 방식의 실제 응용 프로그램(s)do(es),즉 이러한 테스트를 봉사한 다음 예제로 사람을 구현해야 합니다 그러한 응용 프로그램(면 고객들이 판매되고 있는 라이브러리).

그래서,이유로 이동하는 모든 문제가?

개발자 테스트 확인 기능이 작동에 작은 관계없이,어떻게 액세스할(독립의 프레젠테이션 계층 때문에 모든 내부 비즈니스 로직 tier).
귀하의 고객을 테스트하는지 확인 기능이 작동에 큰,다시 방법에 상관없이 그것은에 액세스,인터페이스에서 경계가 귀하의 비즈니스의 논리 계층입니다.
귀하의 통합 테스트를 확인하는 귀하의 프레젠테이션 계층과 함께 작동하는 비즈니스 논리 계층,지금은 관심할 수 있기 때문에 무시 기본 기능(기 때문에 당신이 별도로 테스트를 위).즉,이러한 테스트에 초점을 맞추고 있다 얇은 층의 예쁜 얼굴(GUI?) 고 통신 인터페이스(웹사 서비스는?).
를 추가할 때의 또 다른 방법에 액세스하는 기능을를 추가하기만 하면의 통합에 대한 테스트는 새로운 형태의 액세스(계층 프레젠테이션).개발자와 고객을 테스트하는지 확인 핵심 기능은 변하지 않고 깨지지입니다.
당신이 필요하지 않은 특별한 도구와 같은 도구는 특별 테스트를 위한 웹 서비스를 사용하고 있습니다.당신이 사용하는 도구/구성요소/도서관/기법을 사용하는 것에서 생산 코드,정확하게 당신이 그들을 사용 하에서 이러한 생산 코드입니다.이 테스트를 더 의미 있지 않기 때문에 당신은 테스트를 다른 사람의 도구입니다.그것은 당신과 당신의 시간과 돈지 않기 때문에 당신은 구매,배포,개발 및 유지 관리를 위해 특별한 도구입니다.그러나,당신은 테스트를 통한 GUI(그러지 마!), 필요할 수 있는 하나의 특별한 도구하는 부품(예를들면,HttpUnit?).

그래서,구체적이다.우리가 가정을 제공하려고 일부 기능에 대한 추적을 유지의 식당의 일상 메뉴(우리는 작업에서 메가-corp 그것의 자신의 카페에서 건물처럼,광산)에 자리잡고 있습니다.말하자는 우리 대상으로 C#.

우리는 일부를 구축 C#클래스의 메뉴,메뉴 항목과 다른 세밀하게 조각의 기능과 관련 데이터입니다.우리가 설립하여 자동 빌드(당신이 그렇게,right?) 사용 넝 실행하는 개발자를 사용하여 테스트를 nUnit,그리고 우리는 것을 확인할 수 없습니다 매일 메뉴와 모양에 그것을 통해 이 모든 작은 조각합니다.

우리는 우리의 몇 가지 아이디어는 우리가 가는 곳,그래서 우리는 적용의 외관 패턴을 생성하여 단일 클래스에 노출시키는 소수의 방법에 숨어있는 동안 대부분의 세밀하게 조각합니다.우리는 추가 별도의 설정은 고객의 테스트는 운영을 통해서만 하는 새로운 외관,다만으로 클라이언트는 것입니다.

지금 우리가 결정하는 우리가 원하는 웹 페이지에 대한 우리의 mega-corp 지식 근로자를 확인하는 오늘의 카페테리아 메뉴입니다.우리는 작성 ASP.NET 페이지,그것을 호출의 외관 클래스(게 되는 우리의 모델은 경우 우리가 하고 있는 MVC)고,배포합니다.때문에 우리는 이미 철저히 테스트된 외관을 통해 우리의 고객을 테스트,그리고 있기 때문에 우리의 하나의 웹 페이지 너무 간단하고,우리가 포기 쓰기 자동화된 테스트에 대해 웹 페이지--수동 테스트를 사용하여 몇 가지 동료 지식 근로자가 될 것이다.

나중에,우리는 우리를 추가하기 시작 몇 가지 새로운 주요 기능을 수니다.우리는 점심 식사합니다.우리는 우리의 세분화된 클래스고 해당 개발자가 테스트는 것을 알고,우리의 기존 시험 경비에 대해 우리를 깨는 기존의 기능이 있습니다.마찬가지로 우리의 정면 클래스,아마도 나누는 새로운 클래스(예를 들어,MenuFacade 및 OrderFacade)인터페이스로 성장하고,비슷한 추가하여 우리의 고객을 테스트합니다.

지금은,아마도 변경 내용은 웹 사이트(이 페이지는 웹사이트,right?) 수동 테스트는 흡연 구역이 지정되어 있습니다.그래서,우리에 간단한 도구를 비교 HttpUnit 할 수 있는 nUnit 을 테스트하는 웹 페이지입니다.우리를 구현하는 배터리의 통합/프레젠테이션 테스트,하지만 모의 버전은 우리의 클래스 외관이기 때문에,여기에서 점이 단순히 웹 페이지 작업-우리는 이미 알고 있는 외관 클래스 작동합니다.테스트 푸시 풀 데이터를 통해 모의 외관,유 테스트 데이터를 성공적으로 그것을 만들었습니다.아무것도 없습니다.

물론 우리의 그랜드 성공 메시지를 표시 CEO 를 요청(요청 시)에는 우리가 노출 웹 응용 프로그램를 메가-corp 블랙 베리.그래서 우리는 일부를 구현하는 새로운 페이지고 새로운 배터리의 통합을 테스트합니다.우리는 없을 터치하는 개발자 또는 고객의 시험을,우리가 가지고 있기 때문에 추가되는 새로운 핵심 기능이 있습니다.

마지막으로,CTO 요청(요구)우리는 우리의 카페테리아 응용 프로그램의 모든 메가-사의 로봇자--았다면 그들을 통지 over the last few days?그래서 지금 우리는 웹 서비스에는 레이어를 통해 통신하여 우리의 외관을 하고 있습니다.다시,변경하지 않은 우리의 핵심 기능,개발자 테스트,또는 우리의 고객을 테스트합니다.우리는 적용 어댑터/래퍼 패턴 클래스를 만들어 표시하는 외관과 함께 해당하는 web 서비스 API,우리가 만드는 클라이언트 측 클래스를 소비하는 API 입니다.우리는 추가로 새로운 배터리 의 통합 테스트,하지만 그들이 사용하는 일반 nUnit 을 만드는 클라이언트 측의 API 를 클래스,통신하는 웹을 통해 배선 서비스 서비스-side API 클래스는 호출 모의 외관은 클래스를 확인 우리의 배선을 작동합니다.

참고로 이 모든 과정에 걸쳐 우리가 아무것도 필요하지 않습을 넘어 중요한 플랫폼은 우리의 생산 및 코드,우리가 선택한 개발 플랫폼,몇 가지 오픈 소스 구성 요소에 대한 자동 구축 및 테스트,그리고 몇 가지 잘 정의된 배터리 테스트입니다.또한 우리는 테스트하지 않았다는 것도 우리가 사용하지 않는 생산에서,그리고 우리는 테스트하지 않았다 아무것도 두 번.

우리가 끝났다 솔리드 코어 기능의(비즈니스 논리 계층)을 입증 자체의 성숙(가).우리는 세 가지 별도의 프레젠테이션 계층 구현:웹사이트를 대상으로 데스크톱,웹사이트를 대상으로 블랙 베리 및 웹 서비스 API 를 사용합니다.

지금,나를 용서하십시오 긴 대답--나는 타이어의 부적당한 응답하고 나는 원하지 않았을 제공합니다.이 있는 것을 양해해 주십시오 나는 실제로 이러(은 아니지만 카페테리아 메뉴).

면책 조항 : TypEmock에서 일합니다.

정확히 무엇을 해야하는지 잘 모르겠지만 다음 링크는 좋은 시작이라고 생각합니다.

이것은 내가 여전히 좋은 일반적인 대답을 보지 못한 매우 흥미로운 질문입니다. 어떤 사람들은 soapui를 사용하는 것을 제안하지만 실제로는 아직 테스트 할 시간이 없었습니다. 이 페이지 그것에 흥미로울 수 있습니다.

또 다른 방법은 Webdev.webhost.dll을 어떻게 든 랩하고 그것을 사용하는 것입니다 ... Phil Hakkck은이를 논의합니다. 이 게시물.

이전에도 논의됩니다 여기.

이것에 대한 다른 솔루션을 찾으면 알려주십시오!

이것이하는 방법입니다.

그러나 Richard의 질문으로 돌아가서, 나의 이전 개발 팀에는 해결책이있었습니다. 기본적으로 우리가 한 일은 수신 서비스 요청을 구문 분석하고 사전 설정 응답을 반환하는 일반적인 구성 가능한 httphandler를 작성하는 것이 었습니다. XPath와 같은 조건을 기반으로 다시 전송 된 응답은 구성 가능했습니다.

한동안이 작업을 수행 할 필요는 없었지만 Biztalk 앱을 테스트 할 때 항상 SOAP UI 또는 웹 서비스 스튜디오를 사용했습니다. 노력없이 다른 입력 값을 테스트 할 수있었습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow