Quando parlo di test unitari e mocking ai clienti che non ne hanno mai fatto uso (nemmeno personale ;-)) mi risulta difficile farne cogliere tutti i pregi; la prossima volta mi ricorderò del progetto di cui mi sto occupando questi giorni (o li dirigerò a questo post).
Si tratta di un programma che deve monitorare il flusso di alcune pratiche richieste agli istituti bancari dall’agenzia delle entrate. La richiesta viene ricevuta tramite PEC ed un sistema (esistente) ne interpreta le informazioni e gestisce tutto l’iter (abbastanza complesso). Il mio programma non deve “far altro” che verificare la coerenza di tutte le informazioni sparse tra database relazionali (quello principale e quello “di confronto” per controlli di quadratura) e file relativi alla richiesta presenti su file system locale o server remoti.
Io non dispongo ancora del sistema o di una sua simulazione (alcune parti sono ancora in fase di realizzazione); di fatto non ho né la terra sotto i piedi (db, cartelle, ecc.) né il cielo sopra la testa (l’interfaccia, che non ci sarà mai perché il mio programma sarà lanciato da riga di comando).
Nonostante questo, grazie ai test unitari e al mocking con cui sostituisco alle mie dipendenze esterne (db, file) degli oggetti “finti”, POSSO lavorare alla mia parte verificandone la logica che implemento e raffinando man mano il mio modello del dominio.
Mi sento un pò come se stessi creando un organo artificiale che poi andrò a impiantare nel paziente curandomi solo delle “cuciture”, perché il funzionamento interno l’avrò già provato senza paziente; molto meglio che dover provare l’organo per la prima volta sul paziente!