È considerata 'cattiva pratica' controllare il contenuto del file / la codifica nei test unitari?

Un po 'di contesto: oggi ho dovuto aggiornare un po' di codice SQL fornito da un altro mio collega e, dato che è uno script abbastanza grande, è archiviato come file separato (che viene quindi letto ed eseguito in fase di esecuzione). Nel fare ciò ho reintrodotto accidentalmente due bug che avevamo qualche mese fa, vale a dire:

• Per qualsiasi motivo il file ASCII è stato codificato in UTF-16 (il collega mi ha inviato il file tramite e-mail, il che potrebbe averlo causato).
• Lo script mancava delle SETdichiarazioni iniziali (richiesto a causa di alcune cose del driver sulla produzione, ma non su un'installazione pulita localmente).

Dopo aver eseguito il debug per circa un'ora (di nuovo), ho deciso di scrivere alcuni test unitari per garantire che ciò non si ripetesse più (e includere un modo rapido per risolverlo nel messaggio di asserzione per fornire una soluzione semplice per i futuri sviluppatori).

Tuttavia, quando ho inserito questo codice, un altro collega (che è anche il capo del nostro team) mi viene incontro e mi ha detto che non avrei dovuto ripetere queste cose perché:

"Queste cose non appartengono ai test unitari"

"I test unitari devono essere utilizzati solo per controllare il flusso del codice"

Sono piuttosto in conflitto ora poiché penso ancora che ciò che sto facendo non sia sbagliato, poiché questo bug non verrà reintrodotto in futuro, tuttavia questo collega lavora come senior e alla fine della giornata decide cosa ci dedichiamo. Cosa dovrei fare? Sbaglio a farlo in questo modo? È considerata una cattiva pratica?

Molto probabilmente i test che hai scritto sono più vicini ai test di integrazione o regressione rispetto ai test unitari. Mentre la linea può essere molto sfocata e talvolta si trasforma in pedanteria su ciò che è o non è un test unitario, vorrei tornare dal tuo collega e chiedere dove dovrebbero essere i test che hai scritto poiché aggiungono valore garantendo la correttezza del codice.

Non mi concentrerei molto su ciò che è o non è un unit test e mi rendo conto che anche se si tratta di un test di integrazione, nel test potrebbe esserci ancora valore.

Tecnicamente, non è un test unitario, e più di una fase di validazione. L'approccio corretto dipende davvero da ciò che deve essere il flusso di lavoro. Il vantaggio del team è corretto su quale sia lo scopo dei test unitari. La mia sensazione è che questo sia un caso di utilizzo dello strumento sbagliato per un lavoro che deve ancora essere svolto. Quindi inizia con questo:

Qual è il problema che sto cercando di risolvere?

Secondo la descrizione, è necessario convalidare che gli script del database siano conformi ad alcuni standard.

Quali strumenti / processi sono disponibili per risolvere il problema?

La qualità del codice sorgente viene generalmente controllata da strumenti di analisi statica . Se non si dispone di uno strumento di analisi statica per convalidare il proprio SQL, è possibile creare uno strumento rapido e sporco che esegua il controllo su qualsiasi file SQL passato ad esso. Non fa male controllare se ci sono strumenti di analisi statica in grado di gestire i problemi di cui stai parlando.

Se fai quella parte della tua infrastruttura di build, come incorporarla in Jenkins o qualcosa del genere, può essere applicata a tutti i file SQL nel tuo progetto.

I test unitari risolvono solo il problema per il file corrente.

Come comunico la necessità dello strumento?

È abbastanza facile, parli con il capo della tua squadra. Può collaborare con il proprietario del prodotto e voi per determinare il rischio / rendimento dell'investimento negli strumenti. Se questo è probabilmente un problema una tantum, probabilmente gli utensili sarebbero eccessivi. Se gli strumenti per individuare i problemi più grandi sono facili, può valerne la pena solo per il controllo della sanità mentale.

Il capo della tua squadra potrebbe avere alcune idee che tu (o io) non hai preso in considerazione, in grado di affrontare il problema in modo più corretto.

È buona norma chiamare test che accedono ai file "Test unitari".

Lui: "Queste cose non appartengono ai test unitari"

Tu: "Ha senso, ma non sono riuscito a trovare un posto migliore dove metterli. A che cosa appartengono?"

Sfortunatamente, quali tipi di test esistono e come sono organizzati è interamente specifico dell'azienda. Quindi dovrai scoprire come la tua azienda gestisce questi test.

Se non hai ancora un modo per eseguire test automatici diversi dai Test unitari, l'approccio pragmatico consiste nel contrassegnare i Test unitari che non sono effettivamente Test unitari con un prefisso, finché non ne hai abbastanza per iniziare a capire che tipo di test che hai effettivamente / bisogno. Dopodiché puoi iniziare a organizzare.

Lo dice Michael Feathers nel suo libro Lavorare efficacemente con il codice legacy:

Nel settore, le persone spesso vanno avanti e indietro se determinati test sono test unitari. [...] Torno alle due qualità: il test è veloce? Può aiutarci a localizzare rapidamente gli errori?

Il tuo test ti aiuterà a localizzare rapidamente gli errori e ad eseguirli velocemente? Se sì, allora fallo! Se no, allora non farlo! E 'così semplice!

Detto questo, stai lavorando in un ambiente con altre persone e devi andare d'accordo con loro. Potresti finire per farlo a modo suo, anche se in privato non sei d'accordo.

Ho scritto test simili, a volte, su file di codice sorgente, file di configurazione e così via. Non li chiamerei test di unità perché (a) stanno accedendo al file system e potrebbero non essere ultra-veloci (b) Non mi interessa se vengono eseguiti ad ogni check-in (al contrario di ogni notte in un Server CI).

Potresti chiamarli test di integrazione; certamente, sono più vicini a quella prospettiva rispetto ai test unitari.

Il mio termine per loro è test delle risorse . IMHO, sono del tutto giustificati se eseguiti di notte su un server CI: hanno un costo minimo e, se usati con giudizio, aggiungono chiaramente valore. Una definizione di giudizio : se il test sta verificando un problema che ha causato un problema (come la codifica che menzioni).

Un test unitario consiste nel testare un metodo o "unità" di codice. Stai testando il più piccolo gruppo di logica e codice nel tuo software.

Successivamente, quando ti unirai a quello con altre unità, eseguirai test di integrazione.

Spero che il capo della tua squadra abbia incoraggiato la tua iniziativa e avrebbe dovuto offrire suggerimenti alternativi. Hai sicuramente l'idea giusta.

Il tuo SQL è un codice proprio come qualsiasi linguaggio di generazione inferiore come C # o Java e dovrebbe essere testato come tale. E la verifica e la validazione appartengono a tutti i livelli di test. Quindi le istruzioni di codifica e SET sono incluse, ma non necessariamente testate esclusivamente. Cose generali come le terminazioni di linea o la chiusura di solito puoi semplicemente usare un hook o una funzione SCM.

La migliore pratica consiste nell'eseguire test di regressione per garantire che i bug passati non vengano reintrodotti. Generalmente, i test vengono creati insieme a qualsiasi risoluzione del bug. Se questi bug non sono coperti dai test di regressione a livello di unità / integrazione o di sistema e quindi reintrodotti, si tratta di un problema di squadra, un problema di processo, non individuale.

Il fatto è che gli errori di sintassi, le istruzioni mancanti o i blocchi logici all'interno di una 'unità' non vengono generalmente testati. Stai testando gli ingressi e le uscite dell'unità in diverse combinazioni, testando le molte possibilità che potrebbero essere generate.

Tornando alle dichiarazioni SET mancanti - aiutano a informare le molte possibilità di input e output per cui testare. Quale test scriveresti che NON FAREbbe se ti mancasse un SET scelto?

Se hai file che diventano parte del tuo prodotto, il loro contenuto deve essere corretto. Nessun motivo per non verificarlo. Ad esempio, se hai bisogno di sei immagini 1024x 1024 in alcune cartelle, allora scrivi un test unitario che verifica che tu abbia esattamente quello.

Ma probabilmente non hai solo i file, hai anche del codice che legge i file. È possibile scrivere un test unitario per quel codice. Nell'esempio sopra, la funzione di leggere una delle sei immagini restituisce un'immagine 1024 x 1024 in memoria (o qualunque cosa avrebbe dovuto produrre).

Ad ogni modo, potrebbe non essere un test unitario, ma è un test utile. E se si utilizza un framework di unit test che consente di eseguire un test utile (che non è un unit test), perché non utilizzare il framework di unit test?

Forse sto fraintendendo il tuo problema, ma per me questo suona come un problema che non dovrebbe essere catturato da alcun tipo di test dedicato ma semplicemente dal sistema di controllo della versione . Qualsiasi modifica a una base di codice deve essere rivista patch per patch prima di impegnarsi. Un modo semplice per farlo in git è aggiungere le modifiche con

git add -p

Questo per ogni cambiamento in un file di testo la directory di lavoro ti chiederà se vuoi davvero mantenerlo. Ciò consentirebbe di vedere, ad esempio, la cancellazione di tali " SETdichiarazioni iniziali ".

Nel caso in cui la codifica di un intero file fosse cambiata, sarebbe accaduto qualcosa di diverso: l'algoritmo non avrebbe diffuso il vecchio e il nuovo file e quindi git add -pnon avrebbe aggiunto nulla. Ciò sarebbe quindi visibile nell'altro comando che farei prima di qualsiasi commit, vale a dire

git status

Qui vedresti il ​​file evidenziato in rosso, a indicare che ci sono cambiamenti. Indagare sul perché questi non ce l'hanno fatta git add -prenderebbe rapidamente evidente il problema.

Un altro aspetto da considerare: poiché queste due condizioni sono requisiti per l'esecuzione del programma, non dovresti incorporare la logica vicino alla logica di esecuzione? Voglio dire: testare l'esistenza di un file prima di leggerlo e / o convalidarne il contenuto, giusto? quindi come è diverso? Penso che poiché si tratta di una risorsa esterna al codice, dovrebbe essere convalidata in fase di esecuzione, prima di essere effettivamente utilizzata. Risultato: app più potente, non è necessario scrivere test aggiuntivi.

I test hanno lo stesso codice di tutti gli altri e, se abbastanza complessi, beneficiano anche di ... test unitari. Sembra più semplice aggiungere tali controlli preliminari direttamente nel test.

La maggior parte dei test sono abbastanza semplici da non richiedere questo, ma se alcuni sono sufficientemente complessi, non vedo nulla di fondamentalmente sbagliato in questi controlli preliminari. Naturalmente, anche il test dovrebbe fallire senza di loro, ma un buon test unitario indica anche quale unità sta fallendo.

Uno script che viene utilizzato come parte del test e deve avere determinati contenuti e codifica è probabilmente un'unità. Potrebbe avere molto più codice e logica rispetto al resto del test. Un test con tale script non è il miglior progetto di sempre e, se possibile, dovrebbe essere trasformato in qualcosa di più diretto (a meno che questo non sia un test di integrazione).

In primo luogo, uno degli scopi dei test è impedire che i problemi si ripetano nel codice, quindi è assolutamente necessario continuare a scrivere test di questo tipo.

In secondo luogo, la denominazione è difficile. Sì, questi chiaramente non sono "test unitari", ma possono essere parti desiderabili e necessarie del processo di compilazione, perché ti proteggono da errori evidenti e perché ti danno un feedback sugli errori prima (specialmente dato che non vedi il conseguenze su una casella di sviluppo).

Quindi, la domanda è davvero (dovrebbe essere nel tuo contesto) di più su quando e come vengono eseguiti questi test piuttosto che cosa sono.

Ho usato questo tipo di test ampiamente in passato - ci hanno risparmiato un bel po 'di dolore.

I test unitari riguardano l'esecuzione di un'unità di codice in isolamento per confermare che sta producendo il risultato corretto per l'input corretto. L'isolamento dovrebbe rendere ripetibili sia l'unità sottoposta a test che la prova stessa, ovvero non dovrebbe dipendere o introdurre effetti collaterali.

SQL non è esattamente qualcosa che può essere testato in modo isolato, quindi qualsiasi test di SQL non è esattamente un test unitario e, ad eccezione delle istruzioni SELECT, è quasi certo che abbia un effetto collaterale. Possiamo chiamarlo un test di integrazione piuttosto che un test unitario.

È sempre saggio assicurarsi che qualsiasi difetto che potrebbe essere introdotto possa essere rilevato il più presto possibile nel ciclo di sviluppo e sia utile farlo in modo da facilitare l'identificazione della fonte del difetto in modo che possa essere rapidamente corretto.

I test in questione possono essere ricollocati in modo più appropriato dal corpo dei "test unitari" e collocati altrove, ma non devono essere rimossi del tutto se stanno facendo qualcosa di utile come la protezione contro l'eventuale introduzione di un difetto che potrebbe richiedere ore per tracciare giù.