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.