Come posso ancora usare DDD, TDD in BizTalk?

Question

Ho appena iniziato a lavorare su BizTalk al lavoro e mi piacerebbe continuare a usare tutto ciò che ho imparato su DDD, TDD, ecc. È anche possibile o dovrò sempre usare gli editor di Visio come quando creo cose come condutture e orchestrazioni?

Answer 1

Puoi certamente applicare molti concetti di TDD e DDD allo sviluppo di BizTalk.

Puoi progettare e sviluppare attorno al concetto di oggetti di dominio (anche se in BizTalk e nello sviluppo dell'integrazione trovo spesso oggetti di interfaccia o contratto di progettazione iniziale come un modo più utile di pensare - quali messaggi vengono trasmessi alle mie interfacce). E puoi anche seguire le filosofie del TDD su "Costruisci la cosa più semplice possibile che funzionerà" e "costruisci solo cose che fanno superare i test".

Tuttavia, la tua domanda sembra che tu stia chiedendo di più sui lati del codice di questi approcci di progettazione e sviluppo.

Ho ragione sul fatto che vorresti essere in grado di seguire l'approccio di sviluppo guidato dai test scrivendo prima un test unti che esercita un requisito e fallisce, quindi scrive un metodo che soddisfa il requisito e fa passare il test - tutto all'interno un linguaggio di programmazione tradizionale come C #?

Per quello, sfortunatamente, la risposta è no. La maggior parte degli artefatti BizTalk (pipeline, mappe, orchestrazioni ...) può essere realmente creata solo usando i plugin BizTalk di Visual Studio. Esistono modi per visualizzare il codice c # sottostante, ma non si vorrebbe mai provare a sviluppare direttamente questo codice.

Esistono due strumenti BizUnit e Estensioni BizUnit che offrono una certa capacità di controllare l'esecuzione delle applicazioni BizTalk e testarle, ma questo ti porta davvero al punto di eseguire test di integrazione più controllati e più test-driven .

Le forme che trascini nell'area di progettazione dell'orchestrazione faranno in gran parte il loro compito come un'unità di esecuzione opaca. E orchestrazioni, condutture, mappe ecc ... tutte queste cose sono in gran parte destinate ad essere eseguite (e testate) all'interno di un'intera soluzione BizTalk.

Le buone pratiche di progettazione (prendendo indicazioni da approcci come TDD) porteranno a spezzare le soluzioni BizTalk in blocchi più piccoli, più modulari e testabili, e ci sono modi per testare cose come pipeline in isolamento.

Ma i dettagli dettagliati di TDD e DDD nel codice purtroppo non traducono.

Per alcune discussioni correlate che potrebbero essere utili vedi questa domanda:

Mocking WebService consumato da una richiesta-risposta Biztalk porto

Answer 2

Se utilizzi spesso pipeline e componenti di pipeline personalizzati in BizTalk, potresti trovare utile la mia libreria PipelineTesting. Ti consente di utilizzare NUnit (o qualsiasi altro framework di test che preferisci) per creare test automatizzati per pipeline complete, componenti di pipeline specifici o persino schemi (come schemi di file flat).

È abbastanza utile se usi questo tipo di funzionalità, se posso dirlo io stesso (ne faccio un uso intenso nei miei progetti).

Puoi trovare un'introduzione alla libreria qui e il codice completo su github . C'è anche una documentazione più dettagliata nella sua wiki .

Answer 3

Sono d'accordo con i commenti di CKarras. Molte persone lo hanno citato come motivo per non gradire il framework BizUnit. Dai un'occhiata a BizUnit 3.0. Ha un modello a oggetti che consente di scrivere l'intero passaggio del test in C # / VB anziché in XML. BizUnitExtensions è stato aggiornato anche al nuovo modello a oggetti.

Il vantaggio del sistema basato su XML è che è più semplice generare passaggi di test e non è necessario ricompilare quando si aggiornano i passaggi. Nella mia libreria Extensions, ho trovato l'XmlPokeStep (ispirato a NAnt) molto utile. Il mio team potrebbe aggiornare il passaggio xml del test al volo. Ad esempio, supponiamo che abbiamo dovuto chiamare un servizio web che ha creato un record cliente e quindi controllato un database per lo stesso record. Ora se il servizio web restituisce l'ID (generato dinamicamente), potremmo aggiornare il passaggio del test per il passaggio successivo al volo (ovviamente non nello stesso file XML) e quindi utilizzarlo per controllare il database.

Dal punto di vista della codifica, l'intellisense dovrebbe essere affrontato ora in BizUnit 3.0. La mancanza di un XSD ha reso le cose difficili in passato. Spero di ottenere un XSD che aiuti l'intellisenso. C'erano anche alcuni snippet per una vecchia versione di BizUnit, ma quelli non sono stati aggiornati, forse se c'è tempo ci proverò.

Ma tornando al problema TDD, se prendi un po 'dell'intento dietro TDD - la specifica o l'elemento guidato dal comportamento, puoi applicarlo in una certa misura allo sviluppo di Biztalk anche perché BizTalk è fortemente basato sullo sviluppo guidato dal contratto . Quindi puoi prima specificare le tue interfacce e creare orchestrazioni di stub ecc. Per gestirle e poi costruire il core. È possibile scrivere i test BizUnit in quel momento. Vorrei che ci fossero alcuni strumenti in grado di automatizzare questo processo, ma in questo momento non ci sono.

L'uso di framework come la guida ESB può anche darti una piattaforma di base per lavorare in modo da poter implementare i principali casi d'uso attraverso il tuo sistema in modo iterativo.

Solo pochi pensieri. Spero che questo ti aiuti. Penso che valga la pena blog più approfonditamente. Questo è un buon argomento da discutere. Chiamami in caso di domande o se ne possiamo sempre discutere di più qui.

Cordiali saluti Benjy

Answer 4

È possibile utilizzare BizUnit per creare e riutilizzare casi di test generici sia in codice che in Excel (per scenari funzionali)

http://www.codeplex.com/bizunit

BizTalk Server 2009 dovrebbe avere più testabilità integrata IDE.

Saluti Hemil.

Answer 5

BizUnit è davvero difficile da usare perché tutti i test sono scritti in XML anziché in un linguaggio di programmazione.

Nei nostri progetti, abbiamo "quotato" " parti di BizUnit in un semplice vecchio framework di test C #. Questo ci consente di utilizzare la libreria di passaggi di BizUnit direttamente nel codice C # NUnit / MSTest. Ciò rende i test più facili da scrivere (utilizzando VS Intellisense), più flessibili e, soprattutto, più facili da eseguire il debug in caso di fallimento del test. Lo svantaggio principale di questo approccio è che abbiamo biforcuto dalla fonte BizUnit principale.

Un'altra opzione interessante che prenderei in considerazione per progetti futuri è BooUnit , che è un wrapper Boo in cima di BizUnit. Ha vantaggi simili al nostro "Port" di BizUnit ", ma ha anche il vantaggio di usare ancora BizUnit invece di biforcarsi da esso.