Visual Studio 2010: primo contatto (parte 3)
Autore: Roberto Brunetti - DevLeap
In questa puntata ci concentriamo su Testing & Dubugging.
In VSTS2010 è stato aggiunto il supporto per la validazione della user interface. Si parte da un progetto di test con Add New Guided UI Test.
Si sceglie “Launch recorder to generate code”
L’idea è registrare cosa stiamo facendo e generare il codice per testare user interface WinForm e ASP.NET (e forse WPF già nella release 2010). Per Silverlight probabilmente occorrera aspettare ancora un pò.
Ad esempio eseguendo qualche click su questo form si ottiene questa registrazione
Poi si genera il codice tramite il pulsante evidenziato “Generate Code” (stare molto attenti: si siamo in debug posizionare prima il cursore nel metodo di test prima di generare il codice); meglio lanciare prima l’applicazione e poi registrare, al posto di fare F5 diretto da Visual Studio: almeno in questa prima CTP di ottobre 2008.
Per fare la validazione della UI si prende il UI Control Validator (tasto destro sul metodo o sul recorder a registrazione ferma premere “Add Validation”)
Per attivare il controllo si prende il “cazzillo” bianco in alto a destra del panel UI Control Finder e si fa un drag sul controllo da testare: con le freccie ci si può spostare sui controlli da testare.
Per ogni controllo si fa Add e al termine (done) si vedono le proprietà di ogni controllo e si impostano i valori di test.
In questo caso dichiaro che il checkbox deve essere disabilitato. Come si nota si possono controllare più o meno tutte le proprietà (colori, visibilità, focus, etc)
Al lanio del test creato viene fatta girare di nuovo l’applicazione (compleso l’F5 da VS se è stato registrato o l’apertura del browser, oppure l’applicazione deve essere aperta):
Sono andato anche a fare un giro sul sistema operativo per capire come si muove il registratore, e direi che ci segue molto bene.
Si vede la registrazione del Task Manager.
Per far partire un test si può fare tasto destro sul test e Run oppure, come sempre dalla finestra Test View.
Gli Unit Test aiutano, ma in VSTS 2010 si va oltre con Impact Analysis e Historical Debugger, affrontati in modo introduttivo nella prossima sezione.
Vediamo prima qualche dettaglio sul codice generato dallo strumento “Coded UI Test”.
Oltre al file xxx.cs, visto in precedenza, per il coded test viene creato
1) un file UIMap.uitest
2) un file RecordedMethods.cs
3) UserControl.cs
UIMap.uitest è in xml e contiene per ogni elemento (ad esempio la lstElementi)
Il file .cs allegato contiene le classi che consentono a questo framework di recuperare i controlli, definire i criteri di ricerca dei controlli andando per derivazione di alcune classi base: ad esempio LstElementWindow del file xml precedente è un classe definità così:
Si deriva da WinWindow restituendo nel Get di LstElementList l’elemento di tipo WinList (ricordiamoci che si tratta di una finestra Windows Form).
Il codice dello unit test usa metodi del file RecordedMethods.cs che rappresentano i metodi da lanciare per eseguire il test: questi metodo sono stati creati durante la registrazione:
Questi metodi rappresentano appunto lo unit test da eseguire. Ecco il codice:
Come si nota viene creata la struttura per cercare, nel nostro esempio, il pulsante denominato Controlla (dove “Controlla” è il Text del pulsante) e su questo viene eseguito un click nel punto 39,13.
Il file UserControls.cs (che immagino verrà poi inserito nelle librerie Microsoft e non all’interno di ogni progetto come adesso) contiene la definizione dei vari controlli utilizzati (WinButton, WinCheckBox) e ne definisce le proprietà visibili (e quindi controllabili dalla mascherina di validazione del Coded UI Test).
Software Diagnostics and QoS
Bug Prevention: trovarli il prima possibile è la nostra missione.
Oggi in VSTS 2008: Code Analysis per trovare qualche defect strutturale o codice scritto male, ancora prima di lanciare il codice. Il Profiler inoltre ci da una mano fin dalle prime fasi. Poi ci sono gli Unit Test che possono intercettare i bug, poi in produzione si può fare tracing. VSTS 2010 prosegue su questa linea aggiungendo due strumenti interni e uno strumento esterno.
VSTS2010 prima feature: Impact Analysis
Quando cambio del codice vedo quali test dovrebbero essere lanciati perchè la modifica impatta il codice testato da questo test. Nella finestra selezionare il team project e la relativa build.
Serve una Build perchè il mapping fra test e metodi sta dentro TFS insieme ai risultati dei test. Il file di mapping server-side viene caricato in VS per controllare questo mapping.
Selezionata la Build e modificando qualche riga di codice, al momento del salvataggio viene controllato l’impatto:
In questo caso la modifica che ho fatto (che ha toccato il metodo Somma) non impatta su nessun test. Questo strumento consente di verificare anche il famoso problema “One Code Line Change”: non preoccupiamoci, sto modificando solo una riga di codice, non posso fare casino J. In questo modo sappiamo a colpo d’occhio quali test dover rilanciare. Esiste poi (almeno l’ho trovata nel prodotto) una check in policy che consente di bloccare un check-in se il codice modificato ha impattato su alcuni test che non sono stati lanciati:
Inoltre la finestra “Test Impact Analysis” indica anche tutti i metodi modificati dall’ultimo check-out: è quindi comodissimo anche per capire cosa ha fatto; sembra una cosa stupida, ma durante lo sviuppo di una parte di codice spesso (almeno a me accade) saltiamo da un metodo all’altro, e spesso siamo interrotti da una mail (la prima regola dello sviluppatore è: tenere posta, messenger, skype, telefonino...SPENTI, ma spesso questa non è la situazione classica in molti uffici). Ritornando sul codice occorre capire dove eravamo, cosa avevamo fatto: la finestrina aiuta in questo !
Secondo strumento: Hystorical Debugger
Serve per tornare al punto esatto per capire cosa abbiamo fatto durante il debugging.
Si può vedere cosa è successo prima del nostro breakpoint o dove abbiamo riscontrato un errore: in pratica si può risalire la call stack per capire cosa è successo precedentemente (cosa è accaduto nel metodo che ha chiamato questo metodo).
Facendo un esempio stupido, ma spero calzante: al click di un pulsante eseguo questo codice:
Sperando che si legga nel post (ingrandire l’immagine cliccandoci sopra), si nota che chiamo la funzione Somma, dal click del mio pulsante, una prima volta con due numeri random (potrebbero essere presi ovviamente da un record nel DB o da un file di testo). Al risultato delle mia funzione devo aggiungere un altro valore (sempre random nel mio semplice caso, ma ancora una volta può arrivare da dove vogliamo).
Al primo breakpoint si vede che a e b sono 1402002823. Ecco lo screenshot, notare la finestra “Locals”
Facendo F5 chiaramente mi rifermo al breakpoint di Somma e i due valori saranno diversi, come si nota sempre dalla finestra “Locals”:
Se mi accorgo di un problema sul valore che mi aspetto, ad oggi in VSTS 2008 è difficile capire quali valori erano stati usati nella prima somma (magari i dati nel DB sono cambiati, o il file di testo ha numeri diversi perchè nel processo è stato aggiornato: controllare quindi i dati di origine diventa complicato se non imposssibile) è ed un casino risalire alla natura del problema e capire perchè sono finito in questa situazione.
L’hystorical debugger consente di risalire lo stack per verificare cosa è successo: nella finestra a destra si vede infatti che il Thread 5936 ha eseguito il metodo Main che ha chiamato il form su cui si è eseguito il metodo cmd_HistoricalDebugger (è il nome del mio pulsante) il quale adesso sta eseguendo il metodo Somma. Fin quì niente di particolare: è una call stack.
Se però faccio doppio click sul metodo cmd_HystoricalDebugger vedo che ho eseguito due volte il metodo somma:
E facendo doppio click sul primo ritorno indietro nella storia e posso analizzare nuovamente il contenuto delle variabili sia nella classiche mascherine Auto/Local/Immediate/Watch o nella finestra in basso a destra:
Come si nota si vedono i valori 1402002823 per a e b del metodo somma che erano i valori passati alla prima chiamata a Somma.
Pensato al caso in cui stiamo debuggando il Business Layer su dati arrivati dal DataAccess Layer: ci accorgiamo nell’esecuzione del codice che qualche dato non è come ci aspettavamo; possiamo tornare su cosa ha fatto il DataAccess Layer per capire come mai ci sono arrivati dati strani, possiamo capire se i metodi che abbiamo richiamato hanno fatto il loro lavoro.
Per abilitare o configurare il tutto dal Tools/Options, nella sezione debug.
Terzo Strumento: Test Activity Center “Camano”
Non occorre VS, è una interfaccia stand-alone con accesso diretto a TFS, che presenta i vari test case per ogni progetto.
L’idea è risolvere il problema “It works on my machine” e il Test RePro ovvero il problema di riprodurre un bug che durante la fase di test si è verificato, ma che non “esce fuori” sulla macchina di sviluppo. Migliora anche la collaborazione fra Tester e Developer: sono presenti vari collector (configurabili) per prendere informazioni sul sistema che viene testato (Action Log, Event Log, System Information, Debug Information, Video Recorder anche !). Quindi quando si lancia un test case vengono registrate tutte queste informazioni.
Il test case è composto da varie attività da eseguire manualmente per fare le verifiche. Ogni attività ha poi il flag per indicare se è andato a buon fine o no.
Questa una idea rispetto al form che abbiamo già visto all’inizio di questo articolo. Lavoriamo senza collegare Requirements o Build per semplicità e per rimanere sul punto senza divagare:
Una volta creato il Test Case, dal Test Suite Manager si organizzano i test case in Test Suite. Ad esempio, ho creato una Test Suite denominata Prove UI Manuali che comprende il test case “Visualizzazione Listbox” creato in precedenza:
Per organizzare meglio il lavoro si organizzano i piani di itest in Test Plan: ecco la creazione del Test Plan “Prove su User Interface Manuali” che comprende la test suite appena creata. Per ogni Plan si indicano i classici Test Run, a cui però in VSTS2010 si associa un nome, una suite e una configurazione.
E’ tutto, possiamo tornare sulla home page del menù testing per lanciare il nostro test e raccogliere i dati. Notare nello screenshot seguente la gerarchia appena creata: un Test Run contiene varie Test Suite che a loro volta contengono i test case:
Quindi da “Prove su User Interface Manuali” che rappresenta il nostro piano di esecuzione dei test, si sceglie la suite e al suo interno il test case.
Prima di fare Run assicuriamoci che la nostra Test Settings contenga le informazioni che desideriamo registrare. Ho abilitato quasi tutto J
A questo punto si lancia il test case e con Automation, si registrano tutte le fasi del manual test. Alla fine del processo si può fare il replay delle cose fatte a mano durante la registrazione. Ci sono molti hook nel CLR dove questi strumenti si agganciano quindi non occorre prevedere degli hook nel nostro codice per fare le prime analisi.
Sto ripercorrendo i primi due step che risultano ok e quindi ho marcato come “Pass”:
Adesso clicco sul pulsante Controlla e marco lo step come Pass, ma visto che ripremendo il pulsante non accade quello che ho segnato come controllo sullo step da effettuare marco l’ultimo step come fallito:
Da questo punto posso poi rivedere la registrazione, ripercorrere gli step e controllare eventuali commenti inseriti (ci sono molte opzioni, come ad esempio l’inserimento di checkpoint, ma in questo articolo introduttivo direi di saltarli per non complicarci la vita).
I risultato vengono pubblicati e sono disponibili i report su quanto abbiamo fatto. Nel nostro semplice caso abbiamo un solo test case, in una sola suite, con una sola configurazione, con un solo Test Plan, quindi il risultato è alquanto banale:
Facendo doppio click sul test fallito si apre la maschera di dettaglio:
E ovviamente cliccando sul video (in basso TC280.wmw) si ripercorre cosa abbiamo fatto.
Nel log (TC280.txt) invece sono presenti queste voci:
Se troviamo un bug, alla creazione del bug su TFS vengono aggiunte tutte le informazioni raccolte.
Ovviamente molte di queste operazioni si possono fare da Visual Studio, o meglio dal Team Explorer, da cui poi si possono rivedere i dati. Entrambi gli strumenti lavorano sullo stesso store:
Direi che anche per questo terzo articolo della serie Visual Studio 2010 ci fermiamo.
Alla prossima.
Links a precedenti articoli:
Intro Parte 1 : http://blogs.devleap.com/articolidevleap/archive/2008/10/17/visual-studio-team-system-2010-primo-contatto.aspx
Intro Parte 2: http://blogs.devleap.com/articolidevleap/archive/2008/10/26/visual-studio-team-system-2010-primo-contatto-parte-2.aspx
Link a .NET 4.0
Workflow Foundation 4.0: http://blogs.devleap.com/articolidevleap/archive/2008/11/17/workflow-foundation-4-0-introduzione-alle-ctp-ottobre-2008.aspx
Dublin: http://blogs.devleap.com/articolidevleap/archive/2008/11/14/dublin-windows-application-server.aspx