Test dell'unità Alcuni metodi di servizio Web

Question

Il mio capo desidera che crei una pagina .aspx, caselle di testo per semplificare l'inserimento dei dati della carta di credito in modo da poter testare alcuni metodi nel nostro servizio di carta di credito.

Questo va bene, ma penso che potremmo fare un test unitario per questo. L'unica cosa è, invece di digitare la roba in un modulo web, dovremmo semplicemente cambiare i valori delle variabili passati nel test unitario.

Qualcuno può dirmi se siamo pazzi per non aver fatto un test unitario invece di una pagina .aspx per testare e inserire dati di test per testare alcune chiamate ad alcuni dei nostri metodi?

Finirà per dirmi che Unit Test richiede troppo tempo per l'installazione (come ho cercato di dirgli che dobbiamo fare test di unità) che è una scusa stupida zoppa.

Answer 1

mi sento un po 'in colpa a lasciare una risposta così loquace come ho fatto prima, quindi ecco una più grave prendere su di esso:

Esaminiamo ciò che ci vuole per unit test del servizio. Un vero test unitario è un test automatico che testa una singola unità (nel tuo caso questo sarebbe il servizio web senza alcun sistema di back-end come database, ecc.). Come altri hanno sottolineato, il corretto collaudo dell'unità del servizio è probabilmente troppo tardi in questo caso.

Ciò non significa che non è possibile utilizzare un'unità di test framework (come MSTest, xUnit.net, NUnit, ecc.) Per eseguire i test di servizio. Confrontiamo che scenario per lo sviluppo di una pagina aspx e getta:

• In entrambi i casi ho intenzione di assumere che il servizio Web è già stato distribuito, configurato e in esecuzione, perché sarebbe probabilmente la caso nello scenario di aspx.
• In in entrambi i casi è necessario aggiungere un riferimento di servizio al progetto di test per generare un proxy del servizio Web.
• In in entrambi i casi si dovrebbe scrivere il codice che applica i valori ai parametri di richiesta per i metodi del servizio Web.
• In in entrambi i casi è necessario richiamare le operazioni del servizio Web.

Quindi cosa c'è di diverso?

• Nello scenario aspx, è necessario raccogliere i valori dai campi modulo e assegnare tali valori ai parametri del metodo di servizio. Utilizzando un framework di test, è possibile scrivere direttamente quei valori. In realtà è più facile scrivere il test automatico. 1-0
• Nello scenario aspx, è necessario scrivere codice che raccolga i dati di risposta e li scriva nella pagina Web. Al contrario, con un framework di test, è necessario scrivere asserzioni. Direi che è più facile scrivere asserzioni, ma è un po 'soggettivo quindi lascerò questo come un pareggio - ancora 1-0
• Nello scenario di test automatico, dovrai scrivere molti test con diversi valori, quindi questo è più codice che dovrai scrivere rispetto all'opzione aspx. 1-1
• Con una suite di test automatizzato, è possibile successivamente eseguire la suite di test automatizzato con il database più volte al giorno senza sforzo aggiuntivo, mentre si avrebbe bisogno di input e manualmente manualmente verificare i risultati nel scenario aspx per ogni prova di esecuzione. Questa è una grande vittoria nello sforzo di test. 2-1 (e che è conservatore)

In conclusione, vorrei dire che se non si ostini a fare vera e propria unità di test in questo caso, ma semplicemente di utilizzare un framework di test unità di scrivere automatizzate test, dovresti stare meglio con i test automatici che con la pagina aspx. Lo sforzo di sviluppo sarà più o meno lo stesso.

Per il tuo prossimo progetto, puoi vedere se puoi usare TDD dall'inizio, ma questa è un'altra battaglia.

Buona fortuna.

Answer 2

Invece è possibile scrivere un semplice test .NET (o Java) che chiama il servizio Web e controlla vari scenari, insieme all'evidente vantaggio (è testabile) avrete anche un modo automatico per controllarne le funzionalità.

Il tempo "sprecato" nello scrivere i test unitari sarà riguadagnato dal tempo risparmiato nel testare lo stesso scenario più e più volte anziché eseguire solo i test automatici.

Se il tuo capo non è convinto da quel punto a studi che mostrano TDD/unit tests effectiveness.

Se tutto il resto fallisce, perché non utilizzare uno strumento automatico come soapUI almeno risparmierai manualmente testando la stessa funzionalità più e più volte.

Answer 3

Tu sei pazzo se non unità di prova il servizio web invece di scrivere un test cablaggio manuale :)

In sostanza, un servizio web è un'API a cui si accede tramite un protocollo remoto, in modo non perché unità Provalo?

Answer 4

A mio parere, se si crea la pagina .aspx e si ottiene valore dal modulo Web, sarebbe più un test in tempo reale che un test di unità. Spero che il servizio web sia già stato testato dall'organizzazione, che fornisce questo servizio web. Penso che devi solo creare il modulo .aspx e fare il tuo lavoro.

È possibile eseguire il test delle unità per l'intera soddisfazione del processo di sviluppo. È una buona idea che il test dell'unità debba essere eseguito dalla persona che ha scritto il codice di classe/funzione/metodo web.

Fatemi sapere, se avete qualche domanda.

Answer 5

Se si tratta di un servizio web ASMX, si potrebbe provare ad attivare il protocollo HttpPost nel web.config:

<configuration> 
    <system.web> 
    <webServices> 
     <protocols> 
     <add name="HttpPost"/> 
     </protocols> 
    </webServices> 
    </system.web> 
</configuration> 

Ciò consentirà al modulo di prova per il servizio Web quando si visita la pagina ASMX nel vostro browser. Potrebbe non funzionare bene per tipi complessi; ma se hai tipi complessi, sarà più facile costruire i test unitari di un modulo personalizzato comunque.

L'argomento secondo cui il test unitario è più difficile di un modulo Web sembra errato; se stai sviluppando un modulo, devi comunque scrivere il codice del client del servizio web, oltre a creare la pagina stessa.

Answer 6

Il tuo capo potrebbe voler confermare che il servizio web può essere chiamato da un.aspx page oltre ad essere in grado di provare alcuni valori. (Vuole ad esempio chiamare il codice che qualcun altro deve utilizzare per creare la vera pagina web?) Se il servizio Web chiama servizi esterni e/o utilizza un database, sarà comunque difficile scrivere test di unità automatizzati.

Come scrivere un vero test di unità per il servizio web, penso che questa volta abbia già perso la battaglia ....

La prossima volta prova a scrivere i test delle unità per ciascun metodo che i servizi Web chiamano, poco prima o subito dopo aver scritto il metodo. Non è necessario nemmeno dire al tuo capo che lo stai facendo, poiché ciò produrrà un codice di lavoro più veloce.

Una volta hanno dimostrato l'unità di test aiutano si scrivere codice migliore velocemente si può cercare di introdurre Test Driven Development e/o avere l'unità di test controllano nel sistema di controllo del codice sorgente e le altre persone li esegue quando cambia il codice.

Questa sera potresti sempre passare un po 'del tuo tempo, dopo che il tuo capo è tornato a casa, cercando di scrivere i test unitari. Quindi digli solo quello che hai fatto quando ti chiede perché il tuo codice non ha bug in esso.

Answer 7

È una battaglia che sicuramente perderai. Devi metterti nei panni dei tuoi capi. Ci sono progetti in cui i test unitari potrebbero richiedere troppo tempo, specialmente alla fine del ciclo di sviluppo, quando tutto è affrettato per essere completato. TDD deve essere seguito dall'inizio o perderai troppo tempo nell'implementare i test unitari dopo che hai già dimenticato come funziona uno specifico codice (no, i commenti di solito non sono sufficienti).

Basta fare pratica comune per i prossimi progetti che esegui TDD. Dopo aver testato tutte le unità di codice, è possibile implementare alcuni tipi di test funzionali con strumenti come JMeter e Selenium.

Answer 8

Indovinare che hai già perso la battaglia (ci sentiamo per te). Esistono soluzioni migliori rispetto alla creazione manuale di un utente per il tuo servizio web.

Check out SoapUI. Consuma il tuo WSDL e ti consente di giocare con le richieste xml. Molto facile da collegare a un servizio Web per testarlo, se tutto ciò che vogliono è un POC.