È una cattiva pratica applicare un ordine di esecuzione per i test unitari?

Sto scrivendo test per un progetto che consiste in più sottomoduli. Ogni caso di test che ho scritto viene eseguito indipendentemente l'uno dall'altro e cancello tutti i dati tra i test.

Anche se i test vengono eseguiti in modo indipendente, sto prendendo in considerazione l'esecuzione di un ordine di esecuzione, poiché alcuni casi richiedono più di un sottomodulo. Ad esempio, un sottomodulo sta generando dati e un altro sta eseguendo query sui dati. Se il sottomodulo che genera i dati contiene un errore, anche il test per il sottomodulo di query fallirà, anche se il sottomodulo stesso funziona correttamente.

Non riesco a lavorare con dati fittizi, poiché la funzionalità principale che sto testando è la connessione a un server remoto black box, che ottiene solo i dati dal primo sottomodulo.

In questo caso, è corretto applicare un ordine di esecuzione per i test o è una cattiva pratica? Sento che c'è un odore in questa configurazione, ma non riesco a trovare un modo migliore per aggirare.

modifica: la domanda è da Come strutturare i test in cui un test è impostato da un altro test? poiché il test "precedente" non è un'installazione, ma verifica il codice che esegue l'installazione.

Non riesco a lavorare con dati fittizi, poiché la funzionalità principale che sto testando è la connessione a un server remoto black box, che ottiene solo i dati dal primo sottomodulo.

Questa è la parte chiave per me. Puoi parlare di "unit test" e loro "in esecuzione indipendentemente l'uno dall'altro", ma sembrano tutti che dipendono da questo server remoto e dipendono dal "primo sottomodulo". Quindi tutto sembra strettamente accoppiato e dipendente dallo stato esterno. Pertanto, stai scrivendo test di integrazione. Far eseguire questi test in un ordine specifico è abbastanza normale poiché dipendono fortemente da fattori esterni. Un'esecuzione di test ordinata, con la possibilità di uscire anticipatamente dall'esecuzione di test in caso di problemi, è perfettamente accettabile per i test di integrazione.

Ma varrebbe anche la pena dare un'occhiata alla struttura della tua app. Essere in grado di deridere il primo sottomodulo e il server esterno consentirebbe potenzialmente di scrivere veri test unitari per tutti gli altri sottomoduli.

Sì, è una cattiva pratica.

Generalmente, un test unitario ha lo scopo di testare una singola unità di codice (ad esempio una singola funzione basata su uno stato noto).

Quando si desidera testare una catena di eventi che potrebbero verificarsi in natura, si desidera uno stile di prova diverso, ad esempio un test di integrazione. Questo è ancora più vero se si dipende da un servizio di terze parti.

Per testare le cose in questo modo, è necessario trovare un modo per iniettare i dati fittizi, ad esempio implementando un'interfaccia del servizio dati che rispecchia la richiesta Web ma restituisce dati noti da un file di dati fittizi locale.

L'ordine di esecuzione forzata che proponi ha senso solo se interrompi anche l'esecuzione del test dopo il primo errore.

Annullare l'esecuzione del test al primo errore significa che ogni test può scoprire solo un singolo problema e non può trovare nuovi problemi fino a quando tutti i problemi precedenti non sono stati risolti. Se il primo test da eseguire rileva un problema che richiede un mese per essere risolto, durante quel mese effettivamente nessun test verrà eseguito.

Se non si interrompe l'esecuzione del test al primo errore, l'ordine di esecuzione forzata non ti acquista nulla perché ogni test non riuscito deve essere esaminato comunque. Anche solo per confermare che il test sul sottomodulo di query non riesce a causa dell'errore identificato anche sul sottomodulo di generazione dei dati.

Il miglior consiglio che posso dare è di scrivere i test in modo che sia facile identificare quando un fallimento in una dipendenza sta causando il fallimento del test.

L'odore a cui ti riferisci è l'applicazione di una serie errata di vincoli e regole ai tuoi test.

I test unitari vengono spesso confusi con i "test automatici" o "test automatizzati di un programmatore".

I test delle unità devono essere piccoli, indipendenti e veloci.

Alcune persone leggono erroneamente questo come "i test automatici scritti da un programmatore devono essere piccoli indipendenti e veloci" . Significa semplicemente che se i tuoi test non sono piccoli, indipendenti e veloci, non sono Test di unità, e quindi alcune delle regole per Test di unità non dovrebbero, non possono o non devono applicarsi ai tuoi test. Un esempio banale: dovresti eseguire i test delle unità dopo ogni build, cosa che non devi fare per i test automatici che non sono veloci.

Sebbene i tuoi test non siano Test unitari, significa che puoi saltare una regola e avere l'interdipendenza tra i test, ma hai anche scoperto che ci sono altre regole che potresti aver perso e che dovrai reintrodurre - qualcosa per lo scopo di un'altra domanda .

Come notato sopra, quello che stai eseguendo sembra essere un test di integrazione, tuttavia dichiari che:

Ad esempio, un sottomodulo sta generando dati e un altro sta eseguendo query sui dati. Se il sottomodulo che genera i dati contiene un errore, anche il test per il sottomodulo di query fallirà, anche se il sottomodulo stesso funziona correttamente.

E questo potrebbe essere un buon posto per iniziare il refactoring. Il modulo che esegue query sui dati non dovrebbe dipendere da un'implementazione concreta del primo modulo (generazione di dati). Invece sarebbe meglio iniettare un'interfaccia contenente i metodi per arrivare a quei dati e questo può quindi essere deriso per testare le query.

per esempio

Se hai:

class Queries {

    int GetTheNumber() {
        var dataModule = new Submodule1();
        var data = dataModule.GetData();
        return ... run some query on data
    }
}

Preferisco invece:

interface DataModule {
    Data GetData();
}


class Queries {

    IDataModule _dataModule;

    ctor(IDataModule dataModule) {
       _dataModule = dataModule;
    }

    int GetTheNumber() {
        var data = _dataModule.GetData();
        return ... run some query on data
    }
}

Ciò rimuove la dipendenza dalle query sull'origine dati e consente di impostare test di unità facilmente ripetibili per scenari particolari.

Le altre risposte menzionano che i test di ordinazione sono errati (il che è vero per la maggior parte del tempo), ma c'è un buon motivo per far rispettare l'ordine nell'esecuzione dei test: assicurarsi che i test lenti (ovvero i test di integrazione) vengano eseguiti dopo i test più veloci (test che non si basano su altre risorse esterne). In questo modo è possibile eseguire più test più rapidamente, accelerando il ciclo di feedback.