Corso Test Driven Development a Milano

Aggiornamento: purtroppo il corso non è stato organizzato a causa dell’insufficiente numero di iscritti.

Mercoledi 16 Maggio terrò un corso sull’utilizzo di Unit Test e sull’adozione di Test Driven Development presso la Fondazione dell’Ordine degli Ingegneri della Provincia di Milano.

La giornata sarà focalizzata su tre argomenti principali:

  • l’analisi di costi e benefici dell’adozione del Test Driven Development basata sullo studio di casi ed esperimenti descritti in letteratura;
  • l’illustrazione delle idee alla base del Test Driven Development e una serie di tutorial che mostrano l’utilizzo di alcuni strumenti standard nello sviluppo di una applicazione;
  • come il Test Driven Development si integri in un contesto aziendale esistente e quali possano essere le criticità nella sua adozione.

La locandina contiene il programma dettagliato e le informazioni sul costo del corso.

Affidabilità dei sistemi informatici bancari

Stavo lavorando in una banca ad un porting verso tecnologie attuali di un sistema esistente da qualche anno. Nell’ambito di tale progetto dovevo realizzare un modulo del sistema il cui compito era sostanzialmente quello di estrarre da DB dei record con un campo data maggiore o uguale alla data di odierna, eseguire alcune elaborazioni e scriverli in un file da inviare ad un sistema a valle per una successiva elaborazione.

Il campo che conteneva la data era un campo CHAR di 8 caratteri e ci era stato assicurato che tutte le date erano nel formato YYYYMMDD. In questo modo per selezionare i record con una data maggiore di quella odierna si poteva sruttare l’ordinamento alfabetico e ad esempio scrivere una condizione del tipo

data >= '20052310'

Facendo qualche test mi sono però accorto che in realtà nel db c’erano record con date nel formato DD/MM/YY. La condizione restituiva perciò anche record con valori pari ad esempio a “23/12/98″, “20/10/89″ ed in generale qualsiasi data il cui giorno fosse maggiore o uguale a 20. Questo perchè, in ordine strettamente alfabetico, “23/12/98″ segue “20052310″. I record che avrebbero dovuto essere stati estratti erano qualche decina, invece la presenza delle date nel formato inatteso, ne faceva salire il numero a qualche centinaio.

Dopo un consulto con un programmatore che lavorava alla manutenzione del sistema decidemmo di lasciare i dati scorretti sul DB ma eliminarli nella query di selezione. E quindi in dettaglio la condizione diventò…

data >= '20052310' AND data not like '__/__/__'

Tutto sembrava andare per il meglio, il file contenente i risultati divenne molto più corto e l’elaborazione successiva ne avrebbe certamente giovato.

Mi pareva comunque strano come per i sette o otto anni precedenti il sistema a valle avesse elaborato ogni giorno centinaia di record inutili senza che sollevare il minimo problema.

In fase di test un file campione genenrato dal nuovo sistema doveva essere caricato dal sistema successivo. Il giorno del test ricevetti una telefonata ed il tecnico all’altro capo del filo mi disse che il test era fallito poichè alcuni record contenuti nel file non trovano riscontro nei dati di altre tabelle. Pronto ad affrontare una noiosissima sessione di debug mi accorsi che nel file prodotto non trovavo minimamente traccia dei record errati a cui si era riferito il tecnico.

Dopo una ricerca trovai i record incriminati nel file che era stato prodotto non dal nostro nuovo sistema ma dal vecchio sistema correntemente in produzione. Insomma, per una svista, il tecnico aveva sottoposto a test non il file prodotto dal nuovo sistema, ma quello prodotto quotidianamente, ormai da anni, dal sistema in produzione. E ci aveva trovato pure degli errori!