Technology Experience

Contenuti gestiti da Igor Damiani
posts - 949, comments - 2741, trackbacks - 15120

My Links

News

  • Questo blog si propone di raccogliere riflessioni, teoriche e pratiche, su tutto quello che riguarda il world-computing che mi sta attorno: programmazione in .NET, software attuale e futuro, notizie provenienti dal web, tecnologia in generale, open-source.

    L'idea è quella di lasciare una sorta di patrimonio personale, una raccolta di idee che un giorno potrebbe farmi sorridere, al pensiero di dov'ero e cosa stavo facendo.

    10/05/2005,
    Milano

Archives

Post Categories

Generale

Evento VSTS e qualche appunto sul testing del codice

Voglio fare una classifica della 3-giorni dell'evento Microsoft Visual Studio Team System a cui ho potuto prendere parte grazie all'invito di Lorenzo.

  1. Martedì 30 maggio, dedicata al Team System for Software Developers
    (unit-testing, code-coverage e dintorni)
  2. La mattinata del 31 maggio, dedicata alla teoria del buon testing
    (investire sulla prevenzione del bug, )
  3. Lunedì 29 maggio, dedicata al Team System for Software Architects
    (diagrammi vivi per progettare l'infrastruttura distribuita nella quale gireranno le nostre apps)
  4. Il pomeriggio del 31 maggio, dedicata a test di applicazioni Web
    (c'è bisogno di ricordare che non me ne frega nulla? )

La medaglia d'oro se la aggiudica di gran lunga il Team System dedicato agli sviluppatori, perchè mi hanno esaltato lo unit-testing e il code-coverage unito alle potenzialità comuni alle diverse versioni di Team System. Mi è molto piaciuta anche la mattinata di ieri, dove abbiamo affrontato tutta la teoria riguardante il testare un software, indipendentemente dallo strumento offerto.

Punti essenziali
Il test è una questione che riguarda tutto il ciclo di sviluppo di un software, e riguarda tutto il team coinvolto: dallo sviluppatore a tutti gli altri. Il test è un'attività simile a tutte le altre: va pianificata, monitorata e tenuta sotto controllo. Bisogna pensare a quali parti del software testare, una questione che ogni tanto mi prende buona parte del mio tempo: la mia opinione personale è che occorre considerare quali parti di un software saranno maggiormente riutilizzabili (se trovo un bug nella versione 1.0, tale bug si ripercuoterà nelle x versioni successive) e quali parti sono maggiormente critiche rispetto ad altre.

Mi viene da pensare, per esempio, alla UI di un'applicazione. Difficilmente rimarrà la stessa a lungo, tendenzialmente ad ogni release c'è sempre un processo di ammodernamento per allinearsi ai nuovi standard dettati, nel nostro caso, da Microsoft. Pensiamo a Word: se dovessi decidere io, mi interesserebbe molto di più verificare l'affidabilità dell'object model, perchè magari questo me lo trascino da una release all'altra. La UI invece subisce stravolgimenti ogni volta.

Parlando nel mio piccolo, mi interessa poter affermare che i miei business object siano il più possibile esenti da errori: mi interessa sapere che la proprietà read-only TotaleFattura ritorni davvero il totale dell'importo della fattura. Oppure, che quando elimino tutte le istanze di RigaFattura, il totale della fattura diventi 0. Se i miei business object si comportano correttamente, sono già ragionevolmente sicuro che buona parte dell'applicazione gira bene. Osservazione importante: se un giorno volessi migrare la mia applicazione su altre tecnologie (ASP.NET, Windows Presentation Foundation, tanto per dirne un paio), il domain model rimane sempre quello: se è esente da bug, ho tutto da guadagnarci. Questo si riflette su un'altro punto citato ieri da Lorenzo: prima si trova un bug, minori sono i costi richiesti per fissarlo. Se trovo un bug durante le fasi iniziali di sviluppo (come durante il disegno del domain model), è molto meglio che trovarlo quando il cliente chiama e ci dice: "Uè, nelle Fatture il totale è sempre sballato, ma quell'importo è quello con iva o quello senza? cos'è????".

L'altro punto è sulla criticità di una certa parte di codice. Con unit-testing non mi interessa testare il get;set; di ogni singola property delle mie classi, ma magari le property in read-only che ritornano un risultato calcolato, o magari i salvataggi su database, oppure metodi che fanno calcoli matematici che impattano poi sul data-binding con Windows Form, sulla reportistica, ecc. ecc. Le parti critiche sono quelle parti del codice che vanno ad impattare sul funzionamento di altro codice. Indiana Jones diceva che la X indica il punto dove scavare. Questa regola andrà bene per gli archeologi, ma non per noi sviluppatori: la linea sottolineata in rosso non sempre è la linea che contiene l'errore vero e proprio. Come ha detto Lorenzo, l'errore molto spesso è da qualche parte prima rispetto a quella linea; bisogna quindi risalire il codice e vedere davvero dove si è innescato il meccanismo perverso che ha portato all'eccezione. Ecco il codice critico!

powered by IMHO 1.2

Print | posted on Thursday, June 1, 2006 11:26 AM | Filed Under [ Tecnologia ]

Feedback

Gravatar

# re: Evento VSTS e qualche appunto sul testing del codice

Per quanto riguarda il testing della UI sono d'accordo con te, comunque sarebbe un grandissimo vantaggio poter automatizzare anche questi perchè i test manuali portano via molto tempo.
Non li vedo proprio come Unit Test ma come Acceptance Test http://xp.c2.com/AcceptanceTest.html,
6/1/2006 2:04 PM | Roberto Valenti
Comments have been closed on this topic.

Powered by:
Powered By Subtext Powered By ASP.NET