Idea

Test scritti a posteriori dall'autore del codice convalidano la sua implementazione, non l'intenzione di business

Info

Scritto originalmente in francese. Tradotto dall'IA — il significato è stato preservato, non la prosa.

Idea principale

Un assistente a cui si chiedono i test una volta scritta la funzionalità produce test che passano. È prevedibile: li ricava da ciò che ha appena scritto. Verificano che la funzione chiamata con un certo argomento restituisca quello che restituisce già, che il componente mostri quello che mostra già. Se l'implementazione ha frainteso il bisogno, i test ratificano il malinteso e lo proteggono da qualunque correzione futura.

L'effetto visibile è l'opposto di quello reale. Il repository mostra centinaia di test verdi, la suite gira a ogni modifica e il prodotto sembra al sicuro — mentre niente, in tutto questo, ha mai messo a confronto il codice con il comportamento che il business si aspetta.

È ciò che distingue una copertura da una strategia di test: la prima misura quanto codice viene attraversato, la seconda decide quali comportamenti devono restare veri, a quale livello verificarli e quali rischi vanno coperti.

Perché è importante

Impedisce di leggere la presenza di test come una prova. Su un codice generato, il numero di test è la cifra più facile da ottenere e la meno informativa: bisogna sapere da dove vengono — da un'intenzione formulata prima o da un'implementazione riletta dopo.

Spiega anche perché il tema è difficile per un profilo di prodotto. Non ha per forza pratica di sviluppo guidato dai test, non sempre distingue test unitario, test di integrazione e test end-to-end, e non ha mai dovuto formulare una regola di business sotto forma di verifica: non ha quindi alcun modo di accorgersi che ciò che gli viene restituito è uno specchio.

Sfumature e limiti

Un test scritto dopo il codice non è privo di valore: protegge dalle regressioni, ed è già molto su un codice che nessuno rilegge. Quello che non fa è stabilire che il comportamento fosse quello giusto.

E nemmeno invertire l'ordine basta: un test scritto prima, ma da chi ha frainteso il bisogno, fallisce esattamente allo stesso modo.

Domande aperte

  • Come può chi non ha mai praticato il test esprimere un'intenzione di business in una forma verificabile, senza dover prima imparare il vocabolario del test?