In parole povere: c'è una buona pratica se gli sviluppatori debbano scrivere test automatici per verificare che i dati siano corretti (il contenuto di file di configurazione, database, ecc.)? Se sì, cos'è?
Supponiamo che i dati siano statici per un determinato rilascio e specificati come parte dei requisiti.
Nella maggior parte dei casi questo non ha senso, un test se i dati sono corretti può finire nel confrontare il file A1 con una copia del file stesso A2. Diciamo che hai bisogno di una nuova versione di A1 perché il formato dei tuoi dati si è evoluto nella versione 2.0 del tuo software, lo avresti modificato in A1_V2, e ora il tuo test ti dice che A2 è diverso da A1_V2 - quindi copia A1_V2 in A2_V2 (o modificarlo fino a quando entrambi i file sono uguali di nuovo). Ma se hai commesso un errore nella prima transizione da A1 a A1_V2, ora hai introdotto lo stesso errore in A2_V2 - e il test non lo impedisce. L'unica forma di garanzia della qualità relativa al contenuto di A1 che funzionerà (specialmente se A1 è parte dei requisiti, come hai scritto), è di lasciare una seconda persona a correggere le bozze A1.
Tuttavia, se A1 è in un formato di dati che può essere controllato per coerenza (ad esempio, un file XML, magari con uno schema), allora ha senso avere un test per A1 che sia coerente con quel formato di file. Naturalmente, probabilmente hai già un test di questo tipo, perché se A1 è già parte di un test automatico di un certo codice di produzione, allora questo codice legge A1. E se la routine di lettura è progettata per essere robusta e sicura da errori, come dovrebbe essere qualsiasi codice di lettura, allora questo tipo di controllo di coerenza e mostrerà un errore è A1 è rotto. Pertanto, nella maggior parte dei casi, ciò significa che non è necessario alcun test extra , in particolare per i dati. Ma attenzione: un tale test non garantisce che il contenuto di A1 sia corretto, ti dà solo un controllo formale.
Non c'è, tuttavia, nessuna regola senza eccezioni. Ci possono essere casi speciali (che mi aspetto essere rari) in cui è possibile verificare i dati specifici dei test per contenere alcuni contenuti, magari in forma non ovvia, per accertarsi che il test funzioni come previsto. Ad esempio, potresti avere un database di test complesso e assicurarti che le modifiche manuali successive di quel database non distruggano il set di dieci casi di test ben progettati e non ovvi contenuti in quel database. Quindi avrebbe senso scrivere un test automatico per verificarlo.
Inoltre, se i tuoi dati sono di per sé una sorta di "codice" (ad esempio, alcuni script o funzioni scritti in una sorta di DSL), allora è ovvio che i test automatici hanno senso qui.
Vorrei menzionare che non fa alcuna differenza se non pensiamo che dati o dati di test debbano essere rilasciati alla produzione come parte del tuo prodotto (poiché tali dati possono sempre essere utilizzati come dati di test).
Riassumendo: nella maggior parte dei casi reali suppongo che non abbia senso, ma più i dati sono complessi e le ridondanze implicite o i vincoli formali dei tuoi dati, più test possono essere una buona idea. Quindi pensa al tuo caso reale e applica un po 'di buon senso - che sicuramente ti aiuterà ;-)
Un tester deve controllare la relazione tra input e risultati dei test per verificare in modo affidabile la correttezza dell'esecuzione. Questa relazione è chiamata oracle .
Di solito ciò avviene tramite il possesso dei dati di input, nel qual caso il controllo dei dati è inutile.
Se l'oracolo è semplice, il tester non ha bisogno di controllare i dati di input: esegui l'oracle su input e risultato per sapere se il test ha avuto esito positivo o negativo. Il controllo dei dati è di nuovo inutile. Lo svantaggio è che il tester non controlla il percorso di esecuzione e quindi la copertura del test.
L'unico caso in cui è richiesto il controllo dei dati è quando le assunzioni sono fatte dal software sotto test sui suoi input e questi input non sono sotto il controllo del tester (ad esempio, un algoritmo di divisione che implementa sottostrutture successive: un partitore nullo mette l'esecuzione in un loop infinito).
Non riesco a vedere perché no. Immagina di avere un file di configurazione che contiene una stringa di connessione al database, questo viene eseguito perfettamente sull'ambiente di sviluppo, ma quando si arriva ad eseguirlo nell'ambiente di integrazione esso contiene ancora la vecchia connessione del server DB dev .. disastro! (beh, probabilmente non perché la finestra di sviluppo passerebbe sicuramente tutti i test, ma sarà un disastro se gli script di aggiornamento del DB che hai eseguito per portare il DB di integrazione alle specifiche non funzionavano e non hai mai notato perché tutti i test sono stati eseguiti contro lo sviluppatore DB!)
quindi sì, considererei perfettamente una qualche forma di test per config. La domanda quindi è: quale dovrebbe essere il dato e come si dovrebbe testarlo.
Per testare, suggerirei un insieme di espressioni regex che stampino solo ciò che si aspetta che sia valido. Sarebbe semplice da implementare e potrebbe essere eseguito su qualsiasi forma di file di configurazione (ovvero non è necessario eseguire il parsing di xml o json).
Per la configurazione DB, selezionare e confrontare i contenuti del recordset (valido) è efficace.
Non memorizzare questi test nello stesso punto del resto del codice (o non sarebbe utile verificare che la stringa di connessione sia corretta nell'ambiente di integrazione confrontando l'istanza del server DB con "DEV "- come è probabile che accada se il test e la configurazione sono memorizzati nello stesso posto). Ciò significa che stai meglio con un test di integrazione che può essere eseguito esternamente al codice sorgente principale. E formerebbe anche qualcosa che puoi dare agli ingegneri di supporto per correre contro la configurazione del sito del cliente per verificare se sono quelli giusti, e anche che nessuno ha giocato con loro.