I test di integrazione dovrebbero utilizzare il database? [chiuso]

-1

So che i test di integrazione testano parti del progetto che interagiscono tra loro in qualche modo. E ho bisogno di testare questa interazione. E c'è la domanda:

1) Questi test dovrebbero utilizzare dati di database reali? Voglio dire dovrò connettermi a un vero database?

2) Suppongo di non poter usare un database comune, dovrei usare il mio database privato per questo, ma i miei college non possono usare i miei test perché non avranno il mio database. Cosa fare allora?

3) Dovrò passare i dati reali ai controllori o posso fornire dati casuali? Stessa domanda ai dati del database. Se reale di quanto avrò bisogno di ottenere dati dal browser e le altre cose ...

4) Ho davvero bisogno di questi test di integrazione se ho testato queste interazioni nei test unitari? Ho appena usato i mock invece dei dati reali.

5) Non saranno test di sistema invece di integrazione?

6) I test di integrazione devono utilizzare i dati reali ogni volta?

    
posta Through this pain 07.12.2018 - 13:05
fonte

2 risposte

2

1) Should these tests use real database data? I mean I'll have to connect to a real database?

Se stai testando l'integrazione tra il tuo software e il database, allora sì, dovresti usare il vero database (idealmente fino alla versione che userai in produzione). Se il database non dovrebbe far parte dei test, potresti essere in grado di sostituire un altro meccanismo di archiviazione (potrebbe essere possibile se si utilizza un modello di adattatore o una libreria di astrazione del database). Nota che se scrivi manualmente delle query, l'SQL è probabilmente dipendente dal database, quindi non puoi sostituire un altro database.

2) I suppose I cannot use common database, I should use my private database for this but my colleges cannot use my tests because they won't have my database. What to do then?

Il database utilizzato per i test deve essere utilizzato solo per quel test durante l'esecuzione del test. Successivamente può essere cancellato e utilizzato per un'altra corsa di prova. Pertanto, sono necessari database di test dedicati. Idealmente questo DB viene eseguito localmente sul tuo computer di sviluppo, ma anche la loro gestione centralizzata funzionerebbe (potrebbe anche essere necessario se devi rispettare le licenze proprietarie).

Poiché il software verrà eseguito con diversi database di produzione e test, è necessario che il database specifico sia configurabile, ad es. leggendo una stringa di connessione da una variabile di ambiente. Non inserire le informazioni che differiscono tra gli ambienti nei file di configurazione se tali file di configurazione sono registrati nel controllo di versione. Invece, implementa un modo per utilizzare configurazioni private, ad es. fornendo la configurazione come argomento della riga di comando o come variabili di ambiente. Ovviamente è OK controllare i modelli di configurazione o configurazioni per ambienti specifici, ad es. la configurazione di produzione.

3) I'll have to pass real data to controllers or I can come up with random data? Same question to database data. If real than I'll need to get data from browser and the other things...

Potrebbe non essere consentito utilizzare dati reali a causa di vincoli legali, ad es. norme sulla privacy come HIPAA o GDPR. C'è anche il rischio che i dati reali possano causare accidentalmente azioni reali se la tua configurazione di test è bug, come inviare email o incorrere in addebiti per sistemi di terze parti.

Invece, preferisci simulare uno scenario e usare quei dati. Se il tuo software ha un'interfaccia utente, puoi riprodurre manualmente uno scenario e acquisire questi dati per riprodurli in seguito. Ho anche raccolto i dati dei test analizzando i file di registro a livello di debug e procedendo a scrubbolarli manualmente da qualsiasi dato personale (ad es. Timestamp, indirizzi IP, nomi, e-mail ...).

4) Do I really need these integration tests if I tested this interactions in unit tests? I just used mocks instead of real data.

Se hai usato i mock hai testato metà dell'interfaccia, ma non l'integrazione di entrambe le interfacce. Questo è come testare che una presa elettrica ha potenza e verificare che una spina abbia la forma corretta, ma non verificare se il dispositivo funziona quando lo si collega alla presa.

I test unitari sono molto utili per testare attentamente alcuni componenti in isolamento, ma di solito non sono adatti come strategia di test primaria. Soprattutto per le app Web, di solito è molto più facile eseguire test end-to-end (possibilmente sulla scala dei test di integrazione o di sistema). Gli strumenti di automazione del browser rilevanti sono ampiamente disponibili e ancora più strumenti se hai solo bisogno di testare un'API REST.

5) Won't it be system testing instead of integration?

Un test di integrazione integra alcuni ma non tutti i componenti, altri saranno sostituiti da stub. Un test di sistema include tutti i componenti reali. In genere, i test di integrazione escludono ancora servizi di terze parti e integrano solo componenti locali.

    
risposta data 07.12.2018 - 14:44
fonte
0

È necessario considerare quali parti del sistema si stanno testando insieme.

È solo la convalida del codice che hai scritto ad eseguire le azioni corrette su alcuni dati arbitrari che vengono restituiti? Stai testando i bordi del tuo servizio per verificare che la query corretta sia formata per i servizi esterni e la risposta al tuo client sia formattata correttamente?

Nel caso di test solo il codice che hai scritto può essere utile per deridere le dipendenze esterne dell'applicazione e creare alcuni scenari per le chiamate previste per tali servizi. È quindi possibile restituire una risposta predefinita se tale dipendenza riceve una richiesta corretta.

Quindi forse quando l'applicazione chiama un database, il tuo client DB può essere deriso e puoi verificare se ricevi una query di Select * from Orders where product_name = 'foo' e poi restituire un insieme di Orders che sarebbe rappresentativo della risposta effettiva del tuo database darebbe.

I test vengono eseguiti all'incirca in questo modo:

  • Effettua chiamata all'API dell'applicazione
  • Esegui la normale logica di produzione
  • La dipendenza esterna derisa riceve una chiamata per qualcosa
  • Asserisci che la chiamata esterna sia corretta, quindi restituisci una risposta predefinita
  • Asserisci che la risposta dell'applicazione è la stessa di quanto previsto

L'astrazione dell'hosting dell'applicazione tramite OWIN ti consente di creare un'istanza in-memory della tua applicazione e, sovrascrivendo il tuo contenitore con i mock, puoi ottenerlo in modo abbastanza elegante.

link

    
risposta data 07.12.2018 - 15:31
fonte

Leggi altre domande sui tag