I test di integrazione sono considerati ridondanti?

5

Ecco alcuni codici falsi sotto test:

public void saveItem() {
  try {
    databaseInterface.saveItemToDatabase(item);
  } catch (Exception e) {
      // deal with it 
      return;
  }
  itemList.Add(item);
}

Durante la stesura di un test unitario, se non dovessi spegnere quella chiamata al database, i test engineer direbbero che si tratta di un test di integrazione, non di un test unitario poiché chiama un vero database che rende il test dell'unità lento, e una caratteristica di un test unitario è che dovrebbe essere veloce.

Quindi, interrompi la chiamata al database e verifica se l'elemento è stato salvato nell'elenco, terminando con un test unitario.

Crea anche un test unitario per verificare se la funzione saveItemToDatabase è stata effettivamente chiamata, quindi in questo nuovo test di unità decidi di prendere in giro la chiamata e asserire contro di essa.

Hai anche il compito di testare l'interfaccia del tuo database, per assicurarti che gli elementi vengano effettivamente salvati nel database, quindi fallo.

Tutti i tuoi test passano, quindi ora sai che 1) gli elementi vengono salvati nella lista 2) il tuo metodo saveItemToDatabase viene effettivamente chiamato 3) i tuoi test di unità che coprono il modulo del database mostrano che l'elemento viene effettivamente salvato nel banca dati.

Se sto capendo correttamente il test di integrazione, faresti un test di integrazione, testare tutte queste cose, questa volta usando una vera chiamata al database in un test. Pertanto, in un test di integrazione il test potrebbe eseguire le seguenti operazioni:

  1. Crea un elemento.
  2. Chiama saveItem () (un metodo oggetto) che salverà l'elemento appena creato.
  3. Esegui una query sul database per l'elemento utilizzando l'interfaccia del database.
  4. Verifica che l'elemento creato e il risultato della query siano uguali.
  5. Verifica che l'elemento che hai salvato sia stato aggiunto all'Elenco articoli

Sembra che il test di integrazione stia prendendo tutti i test unitari e ricontrollando ciò che fa ogni test unitario, eccetto che questa volta non stai stubando o deridendo qualcosa, quindi sembra che i test di integrazione siano un po 'ridondanti.

Sto fraintendendo cosa è un test di integrazione? Sembra quasi un test che dice: "Sì, il tuo codice di produzione funziona davvero quando non metti a tacere o derubare cose".

    
posta ShrimpCrackers 06.08.2015 - 06:23
fonte

2 risposte

9

It sort of seems like a test that says, "yes, your production code is actually working when you don't stub or mock things out."

Questo è esattamente quello che è.

Stub e mock isolano l'infrastruttura dai test delle unità, il che significa che le tue unità vengono testate, ma non l'infrastruttura che hai eliminato, né le connessioni che le tue unità realizzano con quell'infrastruttura. È il comportamento delle tue unità e il modo in cui il comportamento interagisce con i componenti effettivi che hai eliminato e che sono stati testati in un test di integrazione.

Ricorda che stub e mock non rappresentano il comportamento reale di un sistema reale; simulano solo un piccolo numero di comportamenti indotti artificialmente in modo da poter eseguire i test unitari. Un test di integrazione non solo fornisce un esercizio più realistico del sistema, ma anche uno più completo.

    
risposta data 06.08.2015 - 09:15
fonte
3

Penso di averlo indietro - il test di integrazione è il test "reale", testando il sistema nel suo complesso. Ma dato che è lento e spesso difficile da configurare, abbiamo dei test unitari come misura stop-gap. Esaminano i bit in isolamento che dovrebbero darti un indicatore che il codice probabilmente funzionerà correttamente quando inviato al test di integrazione.

Puoi scrivere sistemi funzionanti senza test di unità, non puoi farlo senza test di integrazione.

    
risposta data 06.08.2015 - 09:33
fonte

Leggi altre domande sui tag