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?