unità / client di test del servizio Web di test di integrazione

3

Sto riscrivendo una libreria client / proxy PHP che fornisce un'interfaccia a un webservice .Net basato su SOAP e, nel processo, voglio aggiungere alcuni test di unità e integrazione in modo che le modifiche future siano meno rischiose.

Il lavoro su cui sto lavorando è quello di eseguire il marshalling delle chiamate al servizio web e fare un po 'di riorganizzazione delle risposte per presentare un'interfaccia leggermente più orientata verso l'obiettivo del servizio sottostante.

Poiché questa libreria non è altro che un sottile strato in cima alle chiamate al servizio web, il mio presupposto di base è che scriverò davvero i test di integrazione più dei test unitari - ad esempio, non vedo alcun motivo per fingere via il servizio web - il lavoro eseguito dal codice su cui sto lavorando è molto leggero; sta quasi passando la risposta dal servizio al consumatore.

La maggior parte delle chiamate sono operazioni CRUD di base: CreateRole (), CreateUser (), DeleteUser (), FindUser (), & ct.

Inizierò da uno stato di database noto: il sistema che sto usando per questi test è isolato a scopo di test, quindi i risultati saranno più o meno prevedibili.

La mia domanda è questa: è naturale utilizzare le chiamate al servizio web per confermare i risultati delle operazioni all'interno dei test e ripristinare lo stato dell'applicazione nell'ambito di ciascun test? Ecco un esempio:

Un test potrebbe essere createUserReturnsValidUserId () e potrebbe essere come questo:

public function createUserReturnsValidUserId() {
   // we're assuming a global connection to the service
   $newUserId = $client->CreateUser("user1");
   assertNotNull($newUserId);
   assertNotNull($client->FindUser($newUserId);
   $client->deleteUser($newUserId);
}

Quindi sto creando un utente, assicurandomi di recuperare un ID e che rappresenti un utente nel sistema, e poi ripulito dopo di me stesso (in modo che i test successivi non contengano il successo o il fallimento di questo test w / r / t il numero di utenti nel sistema, ad esempio). Tuttavia, questo sembra ancora piuttosto fragile: molte dipendenze e opportunità per i test falliscono e influenzano i risultati dei test successivi, che voglio assolutamente evitare.

Mi mancano alcune opzioni su come disaccoppiare questi test dal sistema in prova, o è davvero il meglio che posso fare?

Penso che questa sia una domanda di test di unità / integrazione abbastanza generale, ma se è importante utilizzo PHPUnit per il framework di test.

    
posta cori 08.10.2012 - 00:19
fonte

3 risposte

6

Purtroppo non ho familiarità con PHP o PHPUnit; quindi mi scuso se questa risposta potrebbe non essere così utile.

Ho esperienza nel provare a fare test nello stile che stai suggerendo e l'ho trovato diventare rapidamente un grosso problema. I test di integrazione che si integrano con il DB devono garantire che, dopo ogni test, o prima di test, il db sia in buono stato noto. Senza questo otterrete molti risultati falsi. Per farlo può essere un problema fastidioso. In entrambi i casi ci vorrà del tempo e sarà lento.

Se il tuo livello è in realtà un sottile strato che prende alcuni dati dal web e lo spinge al livello db dopo (eventualmente) alcune modifiche, convalide, ecc. Suggerisco vivamente di disaccoppiarlo dal web e da il DB. Prendi in giro entrambe le estremità nei tuoi test. I tuoi test saranno piccoli e veloci. Prova separatamente il tuo livello db per assicurarti che faccia la cosa giusta quando il tuo livello di traduzione dice di fare qualcosa.

Poiché non ho familiarità con PHP o PHPUnit, sfortunatamente non posso aiutarti a disaccoppiare e deridere questi elementi.

    
risposta data 18.10.2012 - 00:46
fonte
1

Il tuo cablaggio di test deve avere accesso diretto all'archivio dati per eseguire query sviluppate per il test specifico per convalidare i risultati e la pulizia dopo il test.

Affidarsi ad altre funzioni all'interno del sistema in prova anche se queste funzioni non sono state testate nello stesso test significa che quelle funzioni devono essere corrette al 100% rispetto alle ipotesi che il test sta facendo e, a mio parere, può essere un'assunzione pericolosa .

Non credo che tu possa testare il tuo wrapper unitario - è solo quello e non ha alcuna logica indipendente.

    
risposta data 10.01.2014 - 06:15
fonte
1

Accettando ciò che è @verdammelt, il mocking è dove definiamo un'aspettativa per un dato input, il che significa che stiamo definendo sia l'input che l'output. Se simifichiamo i servizi web in modo simile, potrebbe rivelarsi costoso in seguito.

Quindi abbiamo deciso di non deridere i nostri servizi Web e di esporli a effettivi e amp; valori di spazzatura. Con questo approccio possiamo verificare come reagisce il servizio web e se vengono lanciate eccezioni.

Questa è stata la mia esperienza personale con i servizi web di derisione. Spero che aiuti

    
risposta data 10.01.2014 - 12:40
fonte

Leggi altre domande sui tag