Approccio di test unità guari

5

La mia organizzazione sta investendo tempo nella scrittura di tipi di test errati (test unitari eccessivamente complicati per l'implementazione, richiede molto tempo per creare e spesso rende il sistema più difficile da modificare). Inoltre, il contesto è spesso gettato via e i test sono distorti per migliorare le metriche di copertura.

Le stesse ipotesi inserite nel codice vengono inserite nei test delle unità.

Credo che la copertura del codice sia una metrica fuorviante. Uno può avere una copertura del 100% del codice e ha ancora molti bug, molti casi edge non testati, ecc. La costanza di quanto lavoro ci vuole per ottenere l'ultimo 10% di copertura non fornisce un valore commensale.

I test non funzionano bene come "specifiche leggibili" (un ideale che suona bene sulla carta ma spesso non traduce).

Ho trovato un test che, ad esempio, ha affermato che un determinato menu a discesa "contiene 7 elementi". Ciò non si adatta alle aspettative del mondo reale detenute dagli utenti aziendali o persino tecnici. Sembra che l'autore di quel test fosse solo alla ricerca di "qualcosa da far valere".

Temo che stiamo misurando ciò che è facile misurare su ciò che è importante (anche se forse meno misurabile).

Alcuni test sono scritti a un livello tale da configurare mock per verificare ogni piccolo passaggio dell'implementazione (è stato chiamato Dispose su UnitOfWork)? Ecc.

Preferirei test basati sui risultati - verificare che il risultato sia giusto, il "cosa" e non il "come".

Penso che sarebbe bello fare BDD o ATDD (sviluppo basato su test di accettazione) ma organizzativamente non siamo pronti per un grande cambio di paradigma verso Cucumber o SpecFlow o uno strumento simile (anche se forse è un buon obiettivo a lungo termine) .

Ecco il problema. Se esprimi il desiderio di scrivere meno test, i test zelanti ti guarderanno come se ti stessi rivelando profondamente ignorante / immorale. Forse sto proiettando un po '? Ma nessuno vuole sembrare come se suggerissero di "tagliare gli angoli" per la velocità. Ciò nondimeno, ritengo che il nostro processo sia trascinato dalla cieca adesione a protocolli che non sono sempre appropriati dal punto di vista del contesto.

Esiste una postura di "post-zelotria" sul test che posso iniziare a spostarci verso?

    
posta blaster 21.06.2017 - 16:50
fonte

1 risposta

4

No, non sei pazzo. I test TDD / unità sono ottimi, ma devono essere applicati correttamente.

C'è un fenomeno chiamato codifica / architettura del culto del carico. Questo è quando si applica un approccio senza sapere perché lo stai facendo. Questo sembra essere stato il caso con test automatici sul tuo progetto.

Per me,

  • I test di integrazione automatizzati hanno degli usi, tuttavia, è necessario concentrarsi sui test delle unità quando possibile.
  • Basato sul codice Test automatico dell'interfaccia utente è una perdita di tempo. (Non mi riferisco a una struttura di test come il selenio, che può essere utile)
  • Qualsiasi test più complesso del codice che sta testando è solo un altro potenziale punto di errore, e quindi, nel migliore dei casi, una perdita di tempo

Il tipo di cosa a cui stai facendo riferimento nel tuo progetto è un sintomo di quanto segue:

  • Codice strettamente accoppiato
  • Mancato isolamento della logica di business dai componenti dell'infrastruttura della base di codice

Se il tuo codice era meno accoppiato, sarebbe necessario un minimo di mocking.

Se la tua logica di business fosse correttamente isolata, sarebbe molto ovvio su come scrivere test unitari efficaci e produttivi del tuo codice base.

    
risposta data 21.06.2017 - 17:01
fonte

Leggi altre domande sui tag