Test delle unità e test di integrazione [duplicato]

Question

Test delle unità e test di integrazione [duplicato]

#1 da (7 voti)
#2 da (7 voti)
#3 da (1 voti)

12

Qual è la differenza tra test unitario e test di integrazione quando si tratta di sviluppo web (dove il 90-95% del codice si basa su un database)? Una cosa che faccio sempre è che il test dell'unità non dovrebbe occuparsi dei database e dei test di integrazione. Il problema che ho con questo è che per me ciò significa che l'unica differenza tra test di unità e test di integrazione è l'origine dei dati e se questo è il caso, stai testando la stessa funzionalità. Se la funzionalità testata è la stessa, perché perdere tempo con i test delle unità e testare sempre contro un database?

unit-testing integration-tests database web-development

posta ryanzec 15.08.2011 - 22:54

fonte

3 risposte

Leggi altre domande sui tag unit-testing integration-tests database web-development

Qual è la differenza tra Optionals e tipo Nullable Complessità ciclica quando si chiama lo stesso metodo più volte

score 7 · Answer 1

Il test di integrazione riguarda il test dei punti di integrazione tra 2 o più sistemi, questo potrebbe essere un database, potrebbe essere un servizio Web. qualunque esso sia, è basato sull'interazione, cioè cosa è successo al mio componente quando chiama un stored proc che fa xy e z? Un servizio Web ha cambiato la sua interfaccia?

I test unitari riguardano una singola unità di lavoro. Ogni test di unità dovrebbe testare solo una cosa che il metodo dovrebbe fare, qui è dove estirpare il database e tutte le interfacce o interazioni esterne.

score 7 · Answer 2

A unit test is:

Repeatable: You can rerun the same test as many times as you want.

Consistent: Every time you run it, you get the same result. (for example: Using threads can produce an inconsistent result)

In Memory: It has no "hard" dependencies on anything not in memory (such as file system, databases, network)

Fast: It should take less than half a second to run a unit test.

Checking one single concern or "use case" in the system: (More than one can make it harder to understand what or where the problem is when the problem arises.)

By breaking any of these guidelines, you increase the chance of developers either not trusting or not believing the test results (due to repeated false failures by the tests), or people not wanting to run the tests at all because they run too slowly.

link

Un'altra cosa che non è menzionata sopra è che non dovrebbe fare affidamento su alcuna configurazione speciale. Qualche sviluppatore può controllare una copia del codice sorgente ed eseguire i test unitari?

Con un database si richiede ad ogni sviluppatore di avere la stessa configurazione di configurazione del database. Cosa succede se alcuni sviluppatori non lavorano normalmente con il database?

score 1 · Answer 3

Test unità riguarda esclusivamente il test di un singolo componente (e quindi più semplice del test di integrazione).

Il test delle unità è davvero ottimo per assicurarti che la tua interfaccia pubblica non si rompa durante le correzioni dei bug. Ogni classe (componente) viene testata in isolamento senza utilizzare alcuna dipendenza (le dipendenze vengono solitamente iniettate e prese in giro). Di conseguenza, di solito sei in grado di testare il 100% dei percorsi di esecuzione (ottenendo le tue dipendenze iniettate per darti ogni diverso tipo di risultato (inclusi gli errori)). Ciò sarebbe davvero difficile da ottenere con una vera sorgente di dati poiché la generazione delle risposte di errore è difficile (ad es. DB, come si fa l'eccezione Force DB nel punto corretto del test).

Test di integrazione riguarda il modo in cui i componenti interagiscono.
E come risultato può essere più facile scrivere, ma più difficile da configurare per testare tutte le possibilità.

Qui scrivi test su come i sistemi di componenti lavorano insieme. Verifica che non sia stata deprecata alcuna interfaccia necessaria. Cose del genere.