Scrittura test per codice il cui scopo non capisco

Stai andando bene!

La creazione di test di regressione automatici è spesso la cosa migliore che puoi fare per rendere un componente riparabile. Può essere sorprendente, ma tali test possono spesso essere scritti senza la piena comprensione di ciò che il componente fa internamente, purché comprendiate le "interfacce" di input e output (nel significato generale di quella parola). L'abbiamo fatto più volte in passato per applicazioni legacy in piena regola, non solo per le classi, e spesso ci ha aiutato a evitare di rompere cose che non avevamo compreso appieno.

Tuttavia, dovresti avere abbastanza dati di test e assicurarti di avere una solida comprensione di ciò che il software fa dal punto di vista di un utente di quel componente, altrimenti rischi di omettere casi di test importanti.

È IMHO una buona idea implementare i tuoi test automatici prima per avviare il refactoring, non dopo, in modo da poter eseguire il refactoring a piccoli passi e verificare ogni passaggio. Il refactoring stesso dovrebbe rendere il codice più leggibile, quindi ti aiuta ad aumentare la tua comprensione degli interni a poco a poco. Quindi i passaggi dell'ordine in questo processo sono

1. ottenere la comprensione del codice "dall'esterno",
2. scrivere test di regressione,
3. refactor, che porta a una migliore comprensione degli interni del codice

Un motivo importante per scrivere i test unitari è che essi documentano l'API del componente in qualche modo. Non capire lo scopo del codice sotto test è davvero un problema qui. La copertura del codice è un altro obiettivo importante, difficile da raggiungere senza sapere quali rami di esecuzione esistono e come vengono attivati.

Tuttavia, se è possibile reimpostare lo stato in modo pulito (o costruire il nuovo oggetto di test ogni volta), si possono scrivere test di tipo "trash in-trash out" che si limitano a inviare input per lo più casuali al sistema e osservare l'output .

Tali test sono difficili da mantenere, come quando falliscono, può essere complesso dire perché e quanto sia serio. La copertura potrebbe essere discutibile. Tuttavia sono ancora molto meglio di niente. Quando questo test fallisce, lo sviluppatore può rivedere le ultime modifiche con più attenzione e, auspicabilmente, individuare il bug lì.