Ripensare la strategia di test

2

Lavorando su progetti Plone, il nostro team cerca di ottenere una copertura completa del test almeno per prodotti importanti. Il tipo di test che scriviamo sono unit test, test funzionali e test di integrazione. (Anche stress-test, ma quelli non rientrano nell'ambito di questa domanda). L'obiettivo è almeno due volte: per facilitare gli aggiornamenti e catturare i bug (a volte capita anche nel processo di scrittura dei test).

Tuttavia, Plone / Zope è un sistema complesso e, con anni di esperienza che ho notato, la strategia di test dovrebbe essere ripensata. Prima di tutto, i test unitari, che spesso richiedono un sacco di derisione, non sono (costosi) efficienti. Sono per lo più semplici e utili quando viene scritta una funzionalità core-logic-pesante, come i moduli Python puri, che hanno accoppiamenti trascurabili con Plone / Zope, database, ecc. Raramente ho visto i test unitari catturare tutti i bug, eccetto mentre scrivendoli.

Quindi, quando si fa la solita cosa (scrivere viste / portlet / viewlet), dalla mia esperienza, è molto più efficiente scrivere test funzionali e di integrazione. La logica è che nel caso in cui Plone / Zope cambi (in un aggiornamento) possiamo cogliere i contrattempi nel nostro codice. Le viste di solito non hanno molta logica "algoritmica", incollano insieme diverse fonti di dati (come le query sul catalogo), magari con un po 'di gestione dei moduli e pre-elaborazione per i modelli. Spesso le viste richiamano uno o più strumenti per svolgere alcuni compiti di routine (come ottenere l'albero di navigazione o cercare la radice del sito). Prendere in giro tutto sembra poco saggio. Ad esempio, a volte Plone / Zope cambia alcune impostazioni predefinite in un altro tipo e tutti quei test di simulazione continuano felicemente a funzionare mentre il codice non funziona nell'istanza reale.

I test funzionali / di integrazione possono essere a volte fragili (l'HTML può cambiare), ma sono anche meno costosi da produrre. Forniscono una copertura di base e attivano gli allarmi quando il sistema sottostante cambia. Individuare la fonte di contrattempo di solito non è un problema. ( aggiornamento : errato: localizzare dove fallisce il test di integrazione può essere un grosso problema, ma i nostri test di unità del codice di solito non aiutano.

La domanda è, sto trascurando qualcosa di importante confinando l'unittesting alle funzioni e alle classi, che non richiedono una presa in giro pesante dell'ambiente e sono invece "puramente" logico-pesanti? Non riesco a trovare alcuna giustificazione per scrivere il test unitario "prima", o addirittura per ogni pezzo di codice in Plone / Zope (non intendo il nucleo del sistema, solo le nostre aggiunte per i nostri clienti).

Per rendere la domanda meno basata sull'opinione, ci sono altre ragioni, non ho menzionato o affrontato in precedenza, che richiedono di considerare la scrittura di più unit test (e meno test di integrazione) in una situazione in cui il codice dipende strongmente da un complesso (e un po 'peloso) e il codice serve più da collante per i sottosistemi del framework?

    
posta Roman Susi 29.09.2013 - 21:25
fonte

1 risposta

1

I rarely seen unit-tests catching any bugs at all, except while writing them.

Questa è una buona ragione per continuare a scrivere i test unitari: i test unitari non servono solo per i test di regressione, ma aiutano a guidare la progettazione del sistema. Se i test unitari possono aiutarti a notare i bug nel codice sotto test che puoi quindi correggere al volo, questo è il vero valore proprio lì

It is quite often views call one or more tools to do some routine job (like getting navigation tree or looking up site root).

E ci sono altri due motivi: verifica comportamentale e test di regressione - sapere con certezza al 100% che View X ha fatto una chiamata a lo strumento Y e ha passato il risultato al processore del widget, quindi il motivo per cui il widget Z non è il rendering, deve essere il processore del widget (o qualsiasi altra cosa) e non hai nemmeno devi usare il debugger per risolverlo!

Spotting the source of mishap is usually not an issue.

Molto discutibile e certamente soggettivo (con la lingua ben salda sulla mia guancia!) "beneficio" o almeno "Cibo per il pensiero", spero, inizia con: puoi definire "di solito"?

Nei casi "insoliti" in cui non trovi immediatamente la fonte del problema, perché sono le 2 del mattino e i tuoi occhi stanno sanguinando dal bagliore del monitor ... quanto tempo passi davvero a caccia di problemi? Avete misurato quanto tempo potrebbe impiegarvi in questi casi, confrontando i test di scrittura in anticipo per individuare il problema per voi - se analizzate questo e trovate un guadagno netto in tempo da parte di TDD in anticipo, allora dico che è la vostra linea di fondo .

Ovviamente se l'analisi dimostra che nel tuo caso non ti fa risparmiare tempo, allora c'è una giustificata dimostrazione per non che lo fa - non puoi perdere!

    
risposta data 01.10.2013 - 18:39
fonte

Leggi altre domande sui tag