Metodi di test unitari che chiamano i servizi web dei fornitori

È necessario separare il codice relativo ai servizi Web (ad esempio, l'invio e la ricezione di dati) dal codice che elabora i risultati. Spostare quest'ultimo codice in una classe distinta, rendendo pubblici i metodi necessari. Quindi puoi facilmente testare la logica di elaborazione, separatamente dalle dipendenze esterne.

Inoltre, rendi il tuo codice conforme al principio di responsabilità singola . Come regola generale, sentire la necessità di testare metodi privati è spesso un'indicazione che la classe ha troppe responsabilità, quindi dovrebbe essere refactored in più classi.

Penso che un test con tali dipendenze ( chiamata ai servizi web dei fornitori ) sia un test di integrazione piuttosto che un test unitario.

Come altri hanno affermato, se i tuoi test unitari hanno dipendenze esterne come servizi web o chiamate database, allora NON sono affatto test unitari, sono test di integrazione.

I test di unità reali possono essere eseguiti indipendentemente dai componenti esterni oltre al componente che devono essere testati e dovrebbero essere ripetibili indipendentemente dall'ambiente. Se i servizi web esterni non funzionano, il test dell'unità non dovrebbe fallire.

Ci aggiriamo usando un Mocking Framework. Gli oggetti fittizi ci consentono di creare una simulazione di un componente in modo che il componente nel nostro test dell'unità utilizzi questi oggetti simulati anziché reali. Possiamo iniettare oggetti mock nel componente testabile e specificare quale argomento (o) ci stiamo aspettando, cosa vorremmo che restituisse quando viene chiamato, anche quale eccezione vorremmo che generasse. Consiglio vivamente di leggere di più sull'argomento in quanto migliorerà l'affidabilità e l'indipendenza dei test delle unità.

Per un buon post su diversi C # mocking framework vedi il seguente thread SO:

link

EDIT: Per quanto riguarda la sensibilità, disporrai del fatto che trascuro di menzionare DbUnit o altri strumenti transazionali che possono ripristinare le modifiche al database alla fine del test. Anche questi sono ripetibili e possono essere indipendenti dall'ambiente con i dati di test generati, pertanto in questo caso non è necessario un quadro di simulazione.