WSDL.exe - generazione di un'interfaccia e di una classe concreta per facile falsi/finte successive

Question

È possibile ottenere WSDL.exe per generare interfacce o come classi di calcestruzzo quando genera proxys in un servizio Web?

Stiamo consumando un servizio web di terze parti da un'applicazione ASP.Net e abbiamo generato le nostre classi proxy utilizzando WSDL.exe tutte ottimamente.

Ora voglio scrivere test contro il mio wrapper e le classi di business falsificando il servizio web. Non c'è un'interfaccia o una classe di base astratta per il proxy, e sono contrassegnati come interni, il che significa che non posso ereditarli senza inserire il mio codice di test Fake/Mock nei miei progetti/assiemi commerciali.

È possibile creare manualmente un'interfaccia (utilizzando il programma di ricerca) e modificare la classe, tuttavia se la terza parte modifica il proprio WSDL/servizio Web I oi miei successori dovranno anche modificare manualmente l'interfaccia e classi generate automaticamente, che mai Sembra una buona idea.

Qual è il modo più elegante di fingere o prendere in giro questo servizio? Dovrei mettere il falso nel progetto commerciale? Dovrei modificare manualmente i file e creare un'interfaccia? Dovrei fare qualcosa di completamente diverso?

Answer 1

A destra, richiesto da La risposta di Philip mi ha dato il via, e forse ho trovato una soluzione funzionante. Usando WSDL.exe ho generato le interfacce (usando l'opzione/si) e le classi di proxy normali e aggiunto entrambe al mio progetto di business.

Ho quindi creato una nuova classe che eredita dalla classe concreta E implementa l'interfaccia. Questa piccola classe non conteneva praticamente alcun codice, in quanto i membri concreti ereditati fornivano un'implementazione implicita dei membri dell'interfaccia. Il codice è stato compilato per la prima volta e sono stato in grado di sostituire questa piccola classe "shim" (? Adapter?) Nei miei test di integrazione e di eseguire chiamate contro il server di terze parti live.

Ora posso creare altre classi (mock o falsi) che implementano l'interfaccia e sostituiscono invece la classe "shim".

Modifica: OK, ho lavorato un po 'oltre su questo, e salvo alcune complicazioni sta funzionando.

Il primo problema significativo è che le classi proxy sono ancora contrassegnate come "interne", quindi anche la classe derivata (adattatore/shim) deve essere interna.Questo non è un problema se metti una classe Factory nel tuo progetto di business/assembly che new risale alle classi proxy e le restituisce come interfaccia.

Il secondo problema che ho riscontrato è stato che impostavamo le proprietà URL e timeout del webserice in modo esplicito, ma queste non sono incluse nell'interfaccia, ma sono ereditate da System.Web.Services.Protocols.WebClientProtocol via SoapHttpClientProtocol. Di nuovo, mi sono occupato di questo in fabbrica, poiché è un dettaglio di implementazione che sono felice non nell'interfaccia.

Modifica: Questo sta ancora funzionando bene per me durante il test e lo sviluppo della nostra facciata. Da quando ho ottenuto il proxy dietro un'interfaccia ho anche creato una classe decoratore di logging, che sta catturando molte chiamate di esempio per il debugging e quando il server di terze parti è offline.

ho scritto su quello che ho fatto in un po 'più in dettaglio qui: http://www.flowerchild.org.uk/archive/2010/09/21/mocking-or-faking-or-maybe-stubbing-a-wsdl-exe-soap.html

Answer 2

È possibile eseguire wsdl con lo switch /serverinterface o /si per ottenere interfacce per ogni associazione in wsdl. Questo ha lo scopo di fornire lo scheletro lato server da un documento wsdl, ma le interfacce dovrebbero farti strada - se ho capito bene la domanda.

EDIT - Dopo aver letto il commento, credo che ho frainteso la questione - che si desidera interfaccia client/cemento in modo che è possibile codificare di non contrarre attuazione. Lo switch /si probabilmente non ti darà affatto ciò che desideri.

Non sono a conoscenza di alcun interruttore che possa darti questo comportamento, in quanto wsdl fondamentalmente crea una delle tre cose: 1) classi proxy client: 2) classi astratte server (per la creazione di un'implementazione server) 3) interfacce server (ancora, per creare un'implementazione del server - questo è solo iface invece della classe astratta) Non vedo alcun modo per forzare le classi proxy client ad implementare interfacce (diverse da INotifyPropertyChanged su tipi di dati)

Answer 3

Ho sempre trovato che queste classi generate sono troppo grandi per prendere in giro facilmente (troppi metodi/proprietà).

Piuttosto, creare una facciata o un repository che implementa solo le chiamate necessarie e restituisce gli oggetti stile DTO con solo le proprietà che ti interessano.

Scrivere alcuni semplici test di integrazione sul Webservice reale e quindi prendere in giro la facciata semplificata nel resto dei test.

Un ulteriore vantaggio di questo approccio è che si ottiene effettivamente un livello anticorruzione, quindi le modifiche apportate a terze parti avranno un impatto solo su una piccola area del codice.