Test di integrazione - Quanto costa troppo? [duplicare]

Question

Test di integrazione - Quanto costa troppo? [duplicare]

#1 da (1 voti)
#2 da (1 voti)

0

Prima di tutto non sono sicuro se ho scelto il nome giusto per la mia domanda, non sono sicuro se sono test funzionali o integrazione (o altro). Sto parlando di test che test (o dovrebbe) l'app da una richiesta http al database.

Con semplici controllori in cui interrogano il db per alcuni dati è abbastanza facile testarli. Il problema arriva quando le cose si complicano. Quando gli eventi sono sparati e ci sono pochi ascoltatori, che inviano e-mail, creano pdf, fanno chiamate API. Qual è la migliore pratica in questo caso? Prendi in giro questi eventi e assicurando dai test funzionali che vengono chiamati con i giusti parametri? e unità testare gli eventi e gli ascoltatori? o è più sicuro lasciarli sparare agli eventi e vedere se il risultato è quello previsto?

In altre parole i test funzionali e unitari dovrebbero funzionare insieme e dovrebbero basarsi l'uno sull'altro?

LE: Non sto cercando di vedere i vantaggi dell'unità rispetto all'integrazione, voglio solo vedere come fanno gli altri negli scenari di cui sopra.

unit-testing integration-tests php functional-testing laravel

posta Marius.C 08.12.2015 - 09:55

fonte

2 risposte

Leggi altre domande sui tag unit-testing integration-tests php functional-testing laravel

Pacchetti: forze opposte di riusabilità e sviluppabilità Controlla due volte il blocco dell'inizializzazione che esegue una richiesta web

score 1 · Answer 1

Credo che ciò di cui stai parlando (che collega i livelli) si chiami test di integrazione.

Quanti test di questa varietà dovresti fare? Bene, in primo luogo assumerò che i test unitari siano in atto con una buona copertura del codice.

Dopo, concentrati su:

Linea da corsa

Come dovrebbe comportarsi il software la maggior parte del tempo.

Casi degli angoli noti

Eccezioni alle regole precedenti.

Limite test

Trasmetti i dati al di fuori degli intervalli accettati dei valori di ricerca e ai (e oltre) i limiti dei tipi di dati.

Exotics

Qualsiasi altra cosa rara che non sarebbe coperta da quanto sopra, come le persone che usano il sistema in modo improprio, uno degli strati che scende, che fa cose fuori sequenza ecc.

Chiaramente, più in basso nella lista che otteniamo, più tempo si consuma e meno bug vengono restituiti. Arriva un punto in cui ulteriori test diventano antieconomici / espedienti. Dove esattamente questa linea nella sabbia varia dallo sviluppo allo sviluppo. Se si interrompe il test e gli utenti trovano ulteriori bug, il test chiaramente non è stato sufficiente. In natura, tuttavia, i tempi di prova tendono a essere schiacciati, specialmente i superamenti dello sviluppo. Perché lo sviluppo potrebbe invadere è un argomento completamente diverso.

score 1 · Answer 2

La tua domanda è davvero difficile da rispondere in modo generale. Lo scopo dei test di integrazione è testare quanto più possibile il sistema (idealmente end-to-end), ma più diventa end-to-end, più diventa complesso.

Ad esempio potresti voler garantire automaticamente che i PDF siano generati correttamente con le informazioni e il layout corretti. Questo è possibile ma piuttosto complesso, dal momento che è necessario analizzare e interrogare automaticamente i PDF generati. Se stai dicendo di creare un sistema di fatturazione in cui i PDF sono di importanza critica, potrebbe valerne la pena. In un sistema in cui i PDF sono meno critici, potresti essere soddisfatto con il deridere la generazione di PDF.

Non esistono "best practice" che possano salvarti qui, devi prendere una decisione di trade-off in base alle risorse disponibili e alla tua comprensione dei requisiti aziendali.