Quali sono i vantaggi tangibili dei test unitari adeguati rispetto al test funzionale chiamato test unitari

Un progetto a cui sto lavorando ha un sacco di test legacy che non sono stati correttamente derisi. Per questo motivo l'unica dipendenza che ha è EasyMock, che non supporta statica, costruttori con argomenti, ecc. I test invece si basano su connessioni al database e simili per "eseguire" i test. L'aggiunta di powermock per gestire questi casi viene eliminata come costi proibitivi a causa della necessità di aggiornare il progetto esistente per supportarlo (Un'altra discussione).

Le mie domande sono: quali sono i vantaggi tangibili del mondo REALE di test unitari adeguati che posso usare per respingere? Ci sono? Sto solo diventando un pignolo dicendo che i test di unità cattivi (anche se funzionano) sono cattivi? La copertura del codice è altrettanto efficace?

• risorse

  È necessario un database di test per eseguire i test. L'hardware per eseguire il database è più costoso rispetto all'utilizzo di powermock. Rilasciando le risorse utilizzate per i test unitari sul database, l'azienda non deve aggiornare il server al più presto.

• Affidabilità

  Un test può fallire perché il database è inattivo o in uno stato incoerente. Indovina un po ', le tue build sono fallite perché i DBA hanno bloccato il server di sviluppo durante il giorno per fare alcuni aggiornamenti (e ora gli sviluppatori stanno cercando di capire cosa è andato storto nel codice - quando non è il codice).

• Manutenzione aggiuntiva

  I test possono essere eseguiti in qualsiasi ordine. L'aggiunta o la rimozione di un test non dovrebbe causare il fallimento della suite di test. In esecuzione su un database significa che c'è qualche stato da qualche parte (nel database). In genere, questi test richiedono una manutenzione aggiuntiva per garantire che il database mantenga lo stato corretto per l'esecuzione del test successivo.

• Concorrenza

  Due sviluppatori eseguono i test unitari contemporaneamente. Avere un database significa che i test possono scontrarsi con il database. La soluzione a ciò sarebbe quella di clonare il database per ogni test eseguito, il che è proibitivo su un database reale. Il che porta a un'altra opzione da considerare.

Considera anche l'utilizzo di HSQLDB con qualsiasi dialetto del database che stai utilizzando. In questo modo è possibile creare un database in memoria per ogni test. Viene eseguito un test unitario, costruisce il database necessario, carica i dati, la connessione al database dal codice si collega a HSQLDB ed esegue i dati di test.

Le mie domande sono: quali sono i vantaggi tangibili del mondo REALE di test unitari adeguati che posso usare per respingere?

I test unitari validi sono (per codice pulito e altrove):

• Veloce
• Indipendente
• Ripetibile
• Auto-Convalida
• tempestivo

Non avere veri test unitari viola i primi tre (e di solito l'ultimo). Ciò porta ad alcuni problemi piuttosto significativi:

1. I tuoi test sono lenti. I test lenti vengono eseguiti raramente. I test non eseguiti sono quasi inutili.
2. I test possono fallire a causa di motivi non correlati al codice che stai testando. Ciò rende molto più difficile scoprire perché i test hanno fallito, sprecando tempo e spingendo le persone a incolpare l'ambiente anziché il codice.
3. Man mano che il database cambia, i risultati cambiano. Ottenere alcuni database in uno stato ben noto e coerente per i test è noioso, fastidioso e soggetto a errori.

In generale, la mancanza di isolamento nei test unitari porta a test peggiori che richiedono più tempo per scrivere, più tempo per investire e fornire meno fiducia nella base di codice. Ciò a sua volta porta le persone a scrivere meno test o ignorare di più i test, che è la spirale discendente verso il caos.

I test unitari sono solo uno strumento utilizzato per aiutare uno sviluppatore a fornire codice affidabile. Se pensi come pensa il tuo capo, sarai in grado di convincerlo se ciò che stai proponendo ha senso. Tuttavia, se lo presenti come evangelista su un carro a bande, non otterrai le risorse assegnate. Dovrai spiegargli i vantaggi che ne deriva spendendo il tempo e le risorse per l'adattamento dei test unitari alla tua applicazione legacy.

Hai menzionato i test legacy - ciò implica un codice legacy. Sfortunatamente, adattare i test unitari a un codice che non è stato progettato per essere testato a unità è un processo difficile, che richiede tempo e costoso. Il business case diventa ancora più difficile se si dispone di test che forniscono risultati utili e tutto ciò che si intende ottenere sono (dal caso aziendale POV) test alternativi che forniscono gli stessi risultati. Dovrai concentrarti sul risparmio in termini di costi (tempo) .....

La mia ipotesi è che non sarai in grado di presentare al tuo capo un solido business case perché non ce n'è uno.

Da quello che hai descritto sembra che non ti piaccia il framework di test A e desideri passare al framework di test B, che funzionano entrambi. Succhialo e usa ciò che esiste e funziona, non creare più lavoro reinventando la ruota in modo da poter usare il tuo framework di prova preferito.

Ci vuole più di un desiderio di usare il sapore più recente del framework mensile per giustificare il lancio del codice di lavoro esistente e spendere enormi quantità di tempo e denaro per un vantaggio sostanzialmente zero per gli utenti.

Buoni test unitari forniscono localizzazione. I test funzionali potrebbero indicare che "la funzione Aggiungi utente è interrotta", ma un buon test unitario ti dirà che è rotto perché qualcuno ha modificato il campo USER.LAST_NAME nel database in modo che non sia nullo. È anche possibile testare direttamente piccole modifiche, invece di richiedere un ambiente di test complesso (che potrebbe essere necessario reinizializzare o eliminare alcuni test).