Quali sono i vantaggi tangibili ai test delle unità sul test funzionale chiamati test unitari

• 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 il testing dell'unità rispetto al database, l'azienda non ha bisogno di 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é gli amministratori di database hanno interrotto 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. Correndo contro un database significa che c'è qualche stato da qualche parte (nel database). In genere, questi test richiedono una manutenzione extra per garantire che il database mantenga lo stato appropriato per il test successivo.

• Concorrenza

  Due sviluppatori eseguono i test unitari contemporaneamente. Avere un database significa che i test potrebbero collidere sul database. La soluzione a questo sarebbe clonare il database per ogni test eseguito, che è proibitivo su un vero database. 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. Un test unitario esegue, costruisce il database necessario, carica i dati, la connessione al database dal codice si connette a HSQLDB e funziona contro i dati di test.

My questions are, what are the REAL world tangible benifits of proper unit testing I can use to push back?

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

• veloce
• indipendente
• ripetibile
• Auto-Convalida
• Timely

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 che non vengono 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, perdendo tempo e inducendo le persone a dare la colpa all'ambiente piuttosto che al codice.
3. Man mano che il database cambia, i risultati cambiano. Ottenere alcuni database in uno stato coerente e mantenuto valido 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 forniscono meno fiducia nella base di codice. Ciò a sua volta porta le persone a scrivere meno test o ignorare i test più che è la spirale discendente al caos.

I test unitari sono solo uno strumento utilizzato per aiutare uno sviluppatore a fornire codice affidabile. Se pensi che il tuo capo pensi, sarai in grado di convincerlo se ciò che stai proponendo ha senso. Tuttavia, se la presenti come evangelista su un carrozzone, non otterrai le risorse assegnate. Dovrai spiegargli come si avvale spendendo tempo e risorse per l'adeguamento dei test unitari all'applicazione legacy.

Hai menzionato i test legacy - questo implica il codice legacy. Sfortunatamente, il montaggio di test di unità sul codice che non è stato progettato per essere testato su unità è un processo difficile, dispendioso in termini di tempo e costoso. Il business case diventa ancora più difficile se si hanno test che forniscono risultati utili, e tutto ciò che si otterrà è (dal caso POV aziendale) test alternativi che forniscono gli stessi risultati. Dovrai concentrarti sui risparmi sui costi (tempo) .....

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

Da quello che hai descritto sembra che non ti piaccia il framework di test A e vuoi passare al framework di test B, che funzionano entrambi. Succhia tutto e usa ciò che è esistente e funzionante, non creare più lavoro reinventando la ruota in modo da poter utilizzare il tuo framework di test preferito.

Ci vuole più di un voler usare l'ultima novità del framework del mese per giustificare l'eliminazione del codice di lavoro esistente e la spesa di enormi quantità di tempo e denaro per un vantaggio sostanzialmente nullo per gli utenti.

I buoni test unitari forniscono localizzazione. I test funzionali potrebbero dire che "la funzione aggiungi utente è rotta", ma un buon test unitario ti dirà che è rotto perché qualcuno ha cambiato 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 dover essere reinizializzato o eliminato per alcuni test).