Qual è l'approccio migliore per scrivere test automatici? [duplicare]

1

Scrittura di test in un singolo file o scrittura di ciascun test in un file separato? Ho trovato alcuni vantaggi nel mantenere i casi di test in un file separato.

  1. Manutenzione semplice, migliore leggibilità, test singolo facile da eseguire.
  2. Ci possono essere da 80 a 100 linee di codice per ogni caso di test inclusi i commenti. Diciamo che se scriviamo 10 test in un singolo file allora ci saranno ~ 1000 righe di codice che saranno molto difficili da gestire. In genere avremo più di 10 test in una funzionalità. D'altra parte se lo abbiamo come singolo file possiamo facilmente identificare i test dal nome del file stesso.
posta Karthick 05.12.2013 - 07:41
fonte

2 risposte

4

In un primo momento, la domanda sembra superflua. Per un prodotto di dimensioni decenti, nessuno potrebbe nemmeno pensare di scrivere i test tutti in un singolo file, naturalmente.

Quando si tratta di test funzionali / di performance / integrazione / etc, questi sono solitamente coinvolti nella configurazione e già abbastanza grandi per loro natura, così che la separazione è di nuovo la scelta più ovvia.

Esiste, tuttavia, il caso dei test unitari in cui abbiamo dei vantaggi nel mantenere i test in un singolo file:

  • Se il file di test diventa troppo grande, è un'indicazione che anche l'unità / classe testata è troppo grande. Quindi, quale lato negativo per gli altri test diventa un utile segnale di avvertimento per i test unitari.
  • Hai esattamente tutti i test rilevanti per la rispettiva unità insieme. Altri test, come i test di integrazione, tendono a comprendere più componenti di sistema, il che significa che è intrinsecamente difficile identificare tutte le parti. Per i test unitari, c'è sempre solo quella unità, e non avrebbe molto senso trovare per essa più file di test.
  • Test continui: mentre è possibile eseguire teoricamente l'intera suite di test ogni volta che si salva il file sorgente, ciò è impossibile a causa del lungo tempo di esecuzione di alcuni test più coinvolti. I test unitari d'altro canto dovrebbero funzionare in modo estremamente veloce e avere tutti i test per l'unità in un file, è possibile modificare senza pietà pur avendo la garanzia che su ogni salvataggio viene testata l'unità completa. Questo è possibile in teoria con i file divisi, ma in pratica gli strumenti CT assumono un'unità - un test.

L'ultima ragione di cui sopra è sufficiente per me personalmente a giustificare la mancata divisione dei test unitari. Soprattutto con gli IDE ottieni supporto per cose come lo spostamento tra unità e codice di prova tramite un semplice tasto di scelta rapida, o in altre parole: non c'è assolutamente nessuno sforzo necessario per trovare / eseguire / eseguire qualsiasi cosa con il codice di test pertinente della tua unità. Qualcosa che semplicemente non è più possibile nei test che comprendono più unità.

Quindi, in sintesi, direi che i tuoi vantaggi sono realmente presenti solo per i test non unitari. Quando si considerano i test unitari, è vero il contrario: averli in un unico file significa che sono facili da mantenere e da eseguire, e come spiegato sopra, le dimensioni eccessive sono utili come rivelatore di odori di codice in quel caso.

    
risposta data 05.12.2013 - 08:13
fonte
2

Le linee guida generali sono di imitare i file di codice. Ad esempio,

Se abbiamo due file di classe:

  • dipendenti
  • Dipartimento

Dovremmo creare file di test come di seguito:

  • EmployeeTest
  • DepartmentTest

Anche la denominazione del file di test basato sul file di codice con il suffisso "Test" è una linea guida. Queste linee guida rendono i test facili da strutturare / scoprire, ad esempio, in un grande progetto che non devi dire a uno sviluppatore / tester dove trovare il test per una particolare funzionalità, è intuitivo.

Tuttavia, è solo una linea guida e non una regola.

    
risposta data 05.12.2013 - 09:49
fonte

Leggi altre domande sui tag