Esecuzione di test con Team Build
Una delle peculiarità della Team Build è la possibilità di eseguire una batteria di test in maniera automatica.
Ipotizziamo di avere un progetto ASP.NET MVC (ricordo che alla fase di creazione del progetto viene generata in modo automatico una batteria di test standard, che sarà l’oggetto di questa demo), con i suoi test.
Andando ad accodare una build, per eseguirli è necessario esclusivamente configurare questa sezione della Build Definition:
E questo sarà il risultato:
E nel dettaglio:
Possiamo notare come i test siano stati eseguiti da TFSSERVICE (l’account che fa girare i servizi nel mio dominio) sulla macchina LAB-TFS2010DEMO.
E i test passano tutti 
Come installare Team Explorer Everywhere in Eclipse
Microsoft Visual Studio Team Explorer Everywhere (TEE per gli amici, e per me da grande amante dei TLAs 
) è un prodotto che ci permette di poter utilizzare Team Foundation Server con altri strumenti di sviluppo diversi da Visual Studio, rendendo disponibili le funzionalità di Team Explorer per l’appunto…Everywhere!
E’ composto da un client a linea di comando, e da un plug-in per Eclipse, di cui vedremo ora la procedura di installazione.
Apriamo Eclipse.
Selezioniamo Help –> Install New Software
Avremo una schermata di installazione per tutti i possibili plug-in.
Aggiungiamone uno mediante il tasto Add. Gli dovremo dare un nome ed una location. Nel mio caso, “TEE” ed il percorso del plug-in (io ho utilizzato il locale, ma si può utilizzare senza problemi il media):
Here’s the result 
:
Next…
Ancora Next…
Accettiamo la EULA, e Finish.
Un molto confortante messaggio che ci “invita” a riavviare l’ambiente, o a tentare di applicare i cambiamenti rischiando di “causare errori”…io riavvio, male non fa…
Già fatto?!? Ebbene si. Ed ora?
Beh, nelle Views abbiamo questo…
Provate ad indovinare cosa fa? Allego uno screenshot molto esauriente di Martin Woodward, Program Manager di Microsoft:
oppure consultate il blog di Gian Maria, dove ha postato delle prime impressioni a riguardo
In chiusura segnalo il forum dedicato allo sviluppo in interoperabilità con Team Explorer Everywhere, gestito da Martin Woodward (sempre lui ), qui.
PS.: A nessun Javista è stato fatto del male durante la stesura di questo articolo.
Utilizzo di Test Manager per i piani di test manuali
Con la versione 2010 della famiglia Visual Studio ALM, è stato introdotto il nuovo strumento dedicato ai tester funzionali, Visual Studio Test Manager, che è incluso all’interno delle SKU Ultimate e Test Professional.
Vediamo ora come è possibile utilizzarlo per testare manualmente l’applicazione, e quanto sia elevato il livello di integrazione all’interno del team di sviluppo.
Ipotizziamo di avere una applicazione web, da far testare ad un gruppo di tester funzionali presenti nel nostro gruppo. Utilizzando Test Manager possiamo creare un Test Plan, con all’interno diversi Test Case che descrivono passo per passo le operazioni da eseguire.
In questo caso la demo sarà estremamente banale, ed abbiamo solo un test case. Vediamo com’è fatto:
Come vediamo è estremamente intuitivo: sono presenti le istruzioni per far eseguire al tester (che probabilmente non è una figura tecnica, quindi devono essere scritte in modo “plain”), più tutta una serie di dettagli correlati al Work Item. Vediamo anche una zona “Parameter Values”: è una possibilità in più (necessaria, a mio avviso) che viene data, ossia quella di fornire dei parametri di test comprovati.
Andiamo ad eseguire questo test, e vediamo cosa accade:
Premendo “Run”, compare sul mio monitor un recorder:
![image[25]](http://blogs.academicclub.org/matteo/files/2010/07/image25.png) |
Questo è lo strumento che mi permette di registrare tutti i miei progressi nell’esecuzione del test. Vediamo che viene riportata la lista dei test da eseguire, per ora solo in background. Come si utilizza questa lista? E’ estremamente semplice. Si esegue esattamente quello che si vede riportato all’interno dello statement Per ogni operazione che viene compiuta, si imposta uno stato: Pass, Fail. E chiaramente si possono aggiungere delle note, per qualunque cosa. |
. Se ci sono dei parametri da inserire, questi verranno mostrati all’utente in maniera automatica, cosi come il risultato atteso per quell’operazione. Una volta iniziato il test, eseguo i comandi, quindi vado all’URL indicato:
Eseguo tutto quello che mi si dice ma! C’è un bug! Mi restituisce la sottrazione invece dell’addizione!
Perfetto, imposto il result a Fail, ed aggiungo una descrizione. Inoltre sono abbastanza senior da capire che questo test fallito è un bug evidente della mia “Ultimate Enterprise Application”, quindi provvedo a segnalarlo al team di sviluppo.
Viene creato un nuovo bug, contenente una marea di informazioni utili per la risoluzione del bug (dalle informazioni di sistema, fino ad IntelliTrace, o alla registrazione video, se vogliamo).
Il tutto all’interno dell’ambiente “comfortable” di un tester, senza dover utilizzare uno strumento “ostico” (per un non addetto ai lavori) come Visual Studio.
Upload di un nuovo Process Template in Team Foundation Server
Molti spesso mi chiedono “Ah molto bello l’SDL Process Template! Come lo posso utilizzare?” Oppure recentemente è uscito il template Scrum (quello “strict”, rispetto a MSF Agile 5.0), e sicuramente verrà di nuovo su la stessa problematica.
Si procede in questo modo:
- Scarichiamo il Process Template che ci interessa, ed estraiamolo.
- Localizziamo la cartella contenente il file ProcessTemplate.xml. Questo è il file che mappa tutto il contenuto, le dipendenze, I plugin utilizzati in fase di creazione del progetto, ecc.
- Andiamo ad aprire il Process Template Manager:
- Premiamo il tasto Upload, e ci andiamo a posizionare all’interno della cartella di prima. Missione compiuta
Visual Studio 2010 Visualization and Modeling Feature Pack
Chi mi conosce sa quanto sia affezionato alle features architetturali di Visual Studio, e non ho potuto che essere contento quando ho saputo del rilascio di questo Feature Pack (solo per MSDN Subscribers) atto ad ampliarle.
Vorrei spendere due parole su queste nuove funzionalità, senza entrare nello specifico con delle demo (in fondo, per generare dei diagrammi non c’è bisogno di una mia demo, sarebbe solo ridondante visto che c’è già la sezione di MSDN Library 
).
Punto primo: bidirezionalità.
Posso generare codice da diagrammi UML, e diagrammi UML da codice. E no, non faccio casino se faccio delle prove modificando il diagramma, visto che non è immediata la trasformazione. Usa i template T4, quindi totalmente customizzabili.
Punto secondo: XMI
XMI è uno standard per l’interscambio di informazioni mediante XML, ed è ora ufficialmente supportato. E’ possibile importare degli artefatti UML da altri tool e continuare la modellazione in Visual Studio, utilizzando importandoli come XMI (profili inclusi, volendo).
Punto terzo: integrazione e centralità dell’IDE
Piccolo appunto personale: odio saltellare da uno strumento all’altro, di software in software. Amo poter fare tutto da dentro un’unico “cubicle”, senza dover distogliere continuamente l’attenzione ma seguendo un workflow preciso. Sono l’esasperazione della “comfort zone”.
Un esempio di questo? Ve lo dimostro con le funzionalità del V&M Feature Pack. Posso generare un diagramma DGML per le dipendenze al volo, indicando il sito. Ci lavoro sopra, ed a seguire posso linkare i work item in Team Foundation Server. Tutto da dentro Visual Studio. That’s what I mean.
A mio avviso, pur essendo un Feature Pack ha aggiunto delle chicche molto interessanti. E se è questa la direzione, sono convinto avremo molti altri miglioramenti come questo
Breakpoint enhancements in Visual Studio 2010
Il breakpoint è forse lo strumento più importante del debug, che ci permette di ispezionare il codice a seconda di alcune zone, eventi, ecc che possono interessarci.
Però fino ad oggi avevano un limite a mio avviso abbastanza grande: erano comunque locali.
In Visual Studio 2010 è stata introdotta una fantastica feature che permette di esportare i breakpoint impostati sottoforma di file xml, rendendoli di fatto disponibili al resto del mio team. Come si fa?
Mi spiego meglio…
Ipotizziamo di avere una applicazione qualunque, con impostato uno o più breakpoint, e di averla in esecuzione in debug:
Ora, nella finestra Breakpoints, vedrò quello che ho impostato io manualmente.
Nello screenshot ho evidenziato due tasti:
- Export all breakpoints matching the current search criteria
- Imports breakpoints from a file
Il primo è di una comodità disarmante: mi permette di avere una selezione granulare (notare la checkbox a fianco del breakpoint, e la combobox “Search”) dei breakpoint che voglio esportare, magari da inserire sotto source control in TFS per condividerli con il team di sviluppo.
Il secondo è più easy and immediate: importa il file xml generato
Ma la combobox di cui sopra (“Search”) come viene utilizzata?
Un’altra delle nuove features del debugger è la possibilità di impostare delle label per identificare in maniera esplicita il singolo breakpoint, in questo modo:
…scrivendo semplicemente il testo della label
Risultato?
A labeled breakpoint Ovviamente la ricerca non si limita solamente alla label dei breakpoint, ma va a coprire tutte le sue proprietà:
A volte quelle che possono sembrare features “banali”, risolvono dei problemi che, magari pur non essendo essenziali, necessitano di generosi workaround (se superabili, ovviamente). Questa è a mio avviso una di quelle.
My First TDD Library with Visual Studio 2010
E se volessi fare il contrario? Ossia scrivere prima il test e, a seguire, il codice implementativo (aprire il Merriam Webster alla voce Test Driven Development…).
Bene, con Visual Studio 2010 (come anticipava il mitico Lorenzo) è possibile in maniera estremamente facile
Creiamo un progetto di test (TestTDD0) ed una libreria, vuota (vedremo dopo il perchè):
Il metodo di test che mi trovo davanti è, ovviamente, questo:
Bene, è ora di riempirlo!
Ops, c’è un errore. E qui viene il bello…
Posso dire a Visual Studio di crearmi la classe Customer, la proprietà Name, e la function AddCustomer all’interno della mia library!
Nello stesso modo posso creare quindi la proprietà e la function:
Qual è il risultato? Beh…:D
Lo scheletro della nostra classe è stato implementato
Ovviamente il test fallirà (NotImplementedException),
però abbiamo già ottenuto (free of charge, vedi ancora Merriam Webster…) la struttura.
Generazione degli Unit Test automatica
No, non mi sono convertito ad ALT.NET (non che sia una religione!), sto parlando di una comodissima funzionalità di Visual Studio per la generazione automatica del codice di Unit Test.
Ipotizziamo di avere una libreria, SumLib, con all’interno la classe Sum. Questa classe avrà un metodo Add, che accetta come parametri due numeri e ne restituisce un terzo che ha come valore la loro somma.
Ora, volendo fare Unit Test per la prima volta, come posso farlo? Visual Studio mi rende le cose “facili”
Questo è il codice della classe, la cosa più stupida che ci sia:
Come genero lo Unit Test? Beh, ma col mitico strumento chiamato “tasto destro”! Cliccando col tasto destro del mouse sulla funzione Add, ho questo menù:
“Create Unit Tests…”. Seguendo il wizard…
…vado a creare lo unit test. Che cosa genera? Beh ovviamente il progetto di test, ed all’interno la classe di test. Il codice è il seguente:
Ovviamente per testarlo devo conoscere il funzionamento della mia applicazione, e degli unit test in generale.
La domanda che sorge ora è: perchè c’è sia Assert.AreEqual che Assert.Inconclusive? E’ un modo per far notare che il codice di quel test necessita di essere customizzato. Infatti, valorizzando appropriatamente (due numeri interi qualunque) a e b, inserendo in “expected” la loro somma NUMERICA (non usando il metodo Add, ovviamente!) e togliendo la riga 81 del mio codice (Assert.Inconclusive) ottengo questo risultato:
Un fantastico Unit Test passato
ABC del Gated Check-In
Una delle novità che percepiamo lato client in Visual Studio ALM 2010 in maniera sensibile è la presenza (se impostato, chiaramente ) del Gated Check-In.
Il Gated Check-In è una feature di Visual Studio che, in collaborazione con la Team Build, impedisce di inserire del codice non compilante all’interno del Source Control. Come funziona?
Lo sviluppatore esegue un normalissimo check-in, ma al momento del dialogo con il Source Control, la Team Build intercetta il check-in e ne fa automaticamente uno shelve, presentando all’utente questa maschera:
Ovviamente è possibile bypassarla, ma a rischio e pericolo dell’utente (penso che il SDE/SEM di turno si arrabbierebbe e non poco…)
Una volta che l’utente conferma la decisione di far compilare, la shelve viene compilata (e ne vengono fatti girare i test se presenti). Una volta completata abbiamo (ovviamente) due stati: completata o fallita. Se fallisce, lo shelveset viene rifiutato e rimane in locale nel workspace dell’utente, altrimenti se la compilazione avviene con successo il check-in viene eseguito.
“Come posso impostare il Gated Check-In?”
Molto semplice, è un trigger della Team Build:
quindi tutto molto semplice e lineare. Devo avere anche configurato, ovviamente, il path da compilare all’interno del workspace.
“Posso eseguire più Gated Check-In contemporaneamente?”
No. Le build degli shelveset sono sempre eseguite in serie, e non è possibile avere più di una definizione di build per il Gated Check-In. Nel caso ne avessi due, dovrei selezionarne una. Questo è un limite introdotto per eliminare qualunque possibilità di conflitti (che vanificherebbero il concetto alla base del Gated Check-In).
“Nei miei commenti dei Check-In, dopo aver impostato il Gated, mi trovo sempre “***NO_CI***”. Perchè?”
E’ un commento che assicura l’impossibilità di far scattare un’altra build contemporaneamente a quella del Gated Check-In, e che quindi marca quel Check-In come “verificato da un Gated”.
Coded UI Test, chi dove quando…
Una grande novità lato client di Visual Studio 2010 è rappresentata dalla possibilità di avere dei test direttamente sulla User Interface in maniera rapida, il cosiddetto Coded UI Test. Vediamo come…
Ipotizziamo, per semplicità, di voler testare la Calcolatrice di Windows (calc.exe).
L’unico strumento di cui avremo bisogno è il Coded UI Test Recorder, oltre ovviamente a Visual Studio.
Andiamo a creare un nuovo Test Project:
Ovviamente sceglierò un Coded UI Test
Mi apparirà questa schermata:
che mi chiede se registrare azioni da zero, oppure usarne di esistenti. Scelgo la prima opzione. Il risultato è l’apertura del Coded UI Test Builder:
Scelgo di iniziare la registrazione, cliccando sul bottone apposito.
Registrazione partita:
Ora faccio partire il mio applicativo, ipotizziamo di fare una somma 3 + 2, il cui risultato mostrato è (a meno di bug 
) 5. Interrompo la registrazione, e chiedo al tool di generare il codice per il mio test.
Darò un nome al mio metodo:
E troverò il codice all’interno del file in Visual Studio. Questo è il risultato (in questo caso in C#).
Notiamo come vengano riconosciuti i controlli. Perchè?
I Coded UI Test si basano sulle tecnologie per l’accessibilità di Windows (MSAA, UI Automation Library) oppure per il web quindi possono testare “quasi” ogni applicativo (sostanzialmente deve avere controlli WPF, Win32 o che si appoggino* ad esso…)
Ovviamente se andrò ad eseguire il test…magia! Si aprirà automaticamente la calcolatrice, e vedrò l’esecuzione della somma 3+2.
Esiste un Power Tool (beta) che abilita i Coded UI Test per applicazioni web e siti con Firefox 3.5 e 3.6 (oltre a IE 7 ed 8).
Sul blog di Gautam Goenka troviamo inoltre come l’architettura dei Coded UI Test sia estendibile.
*UNSUPPORTED! Ma Qualcuno (:D) è riuscito ad eseguire Coded UI Test su Eclipse.