Cosa testare?

Decidere cosa e come testare è a volte più importante e più difficile della capacità di usare gli strumenti di testing.

Ieri ho scritto degli appunti sul come testare componenti vue.

Una cosa che oggi mi ritrovo a pensare è cosa testare all’interno di un componente vue.

Uno dei non detti del TDD e in generale delle pratiche di testing è quella che bisogna sviluppare la capacità di individuare cosa sia meritevole di testing e cosa no.

Questa capacità viene sviluppata col tempo, con la pratica e con la conoscenza dello stack tecnico con cui si va ad operare.

Testare è importante e fondamentale. Fa conoscere il software nei suoi meandri e migliora la qualità del codice. Ma per raggiungere questi risultati ci vuole tempo e pazienza.

Per questo ora mi sento nuovo e un pò bloccato davanti al mondo del TDD im ambito frontend.

La mia esperienza di TDD con Ruby On Rails

La pratica di testare con Rails ha creato nella mia mente una serie di priorità e principi su ciò che è realmente importante testare. Tale selezione è frutto di anni, di esperienze e di compromessi con la squadra di lavoro.

Queste priorità sono spesso in disaccordo con i principi base che la comunità di sviluppatori indica come importanti da testare. Io personalmente e il mio team adoriamo i test di integrazione dei controller. Danno un punto preciso di entrata, se qualcosa si rompe nella maggior parte dei casi lo si viene a sapere.

Ovviamente trovo molto importante testare anche le operazioni business complesse etc; almeno su questo siamo in linea con la comunità di sviluppo del tdd :-).

Nel tempo mi sono trovato più a mio agio con le fixtures invece che con le factories.

In generale ci siamo decisamente attenuti alle linee guide che DHH e il suo team di sviluppo hanno imposto.

Tra le pratiche che ritengo positive c’è quello di essere riuscito a evitare il mocking totalmente. Qualche chiamata a servizi di terze parti probabilmente potrei evitarle ma con la gemma vcr ho risolto tutte le situazioni e non mi sono mai trovato nella necessità di fare mocking di qualsiasi cosa.

Di recente a lavoro è arrivato un progetto Hanami pieno zeppo di mocking e di factories. Devo dire che il mio cervello ne ha sofferto parecchio e ho capito quanto possa essere diverso l’approccio alla questione.

Ma quindi Vue.js?

La scrittura di questo articolo nasce proprio dalla necessità di enunciare dei principi base da cui partire (per poi disattenderli molto probabilmente!).

Il libro che sto consultando parla in modo abbondante di mocking. Il libro stesso sottolinea quanto sia importante non abusarne. Eppure ne fa ampio uso per quella che è la mia sensibilità.

Mi sono già trovato a fare dei test con delle premesse lunghissime di mocking e di spie. Questa cosa la trovo decisamente sbagliata.

Diciamo che sono nella fase del TDD in cui inizio ad avere la tecnica ma mi manca completamente una capacità di soluzione reale del problema.

Ho trovato molto interessante la guardia tramite snapshot. È qualcosa che vorrei avere anche con Rails.

Alcuni principi

Come riferimento ho usato i seguenti link:

Parti dalla interfaccia esterna

È importante trattare il componente come una scatola nera di cui conosciamo solo i punti di entrata.

Meglio se i componenti sono basati sulle props

Un componente che dipende unicamente dalle props è un componente semplice da testare.

Identifica input e output

È molto importante identificare il prima possibile l’input e l’output che si desidera per un componente.

Evita di testare la libreria o librerie esterne

Attieniti al testare il componente. Non testare il linguaggio; il framework o gli altri componenti.

Mettete i test accanto i componenti

Per non perdere di vista i test è meglio averli accanto ai componenti. Questo è un approccio molto interessante e diverso da quello cui sono abituato con Rails. Il principio mi piace. Credo molto infatti che il detto “lontano dagli occhi, lontano dal cuore” si possa applicare anche ai test unitari. Quindi la configurazione consigliata di Jest che mette i test accanto ai componenti sia un ottimo consiglio perché permette di avere sempre sotto controllo il test.