Come ci racconta benissimo Lorenzo nei suoi webcast, le checkin policy sono uno strumento che permette di assicurare che il checkin del codice sorgente su TFS sia sottoposta a determinate condizioni. E' quindi possibile obbligare lo sviluppatore a far sì che i file pending siano associati ad un workitem, soddifino la validazione del codice con FxCop, piuttosto che passino gli unit test.
Proprio la policy fornita da TFS per validare i test soffre a mio avviso (e leggendo in giro non sono l'unico) di gravi problemi. E' infatti necessario configurare la policy in modo da associargli le liste dei test (chiamate List of Tests) di cui sarà controllato l'esito prima del checkin. Qui nascono i problemi. Le liste dei test sono contenute nel test Metadata File (*.vsdmi) ed è possibile definirle tramite il Test Manager che purtroppo è contenuto solo nelle versioni Visual Studio 2005 Team Suite o Visual Studio 2005 Team Edition for Software Testers (questa limitazione dovrebbe essere risolto in Orcas). Chiunque usi la versione Visual Studio 2005 Team Edition for Software Developers (la versione più diffusa da chi sviluppa e quindi da chi deve essere controllato che il codice scritto sia testato correttamente) non può creare in modo comodo le liste dei tests utilizzate dal Testing Checkin Policy. Per risolvere questo "piccolo" inconveniente, la strada più semplice è quella di utilizzare un tool di terze parti che offra le stesse funzionalità del Test Manager. Ad oggi l'unico che conosco (e funziona egregiamente) è il Test Manager Add-in di cui è possibile trovare una versione trial qui. E' anche possibile scriversi un proprio programma che editi i file vsdmi ma credo che il tempo necessario superi i 90 dollari del costo del tool.
Problemi finiti? Direi di no. Ammesso che riuscissimo a creare/modificare le liste dei test in modo agevole, esiste il forte rischio (anzi deve essere così altrimenti vuol dire che il codice non è testato) che più sviluppatori aggiornino in locale le liste dei test (e di conseguenza il file dei metadati). Poichè il file vsdmi fa parte dei file sotto source control, ci troveremmo di fronte a dover effettuare di continuo merge del file contenente i metadati dei test. Peggio ancora, se lo sviluppatore si dimentica di aggiungere i test appena creati nella lista dei test usata dalla policy, c'è il rischio che sia possibile il checkin di codice con test potenzialmente non passati (sperando che ci siano strumenti di continuos integration che mi segnalino il problema il più velocemente possibile). Io voglio (lo so sono maleducato si dice 'vorrei') che tutti i test creati siano sottoposti automaticamente alla policy di checkin. E se lo sviluppatore non scrive alcun test? In questo caso voglio (o vorrei:P) che il checkin sia bloccato se il codice sorgente non è coperto adeguatamente dai test.
Visto che sono maleducato e tutte queste cose le voglio (non 'le vorrei'), la soluzione è stata quella di scrivermi una custom policy checkin:D CheckTestResultPolicy controlla se esistono risultati di test validi (ovvero posteriori all'ultima modifica dei sorgenti), li analizza e nega il checkin se esistono dei test non passati e se la percentuale di code coverage non è almeno pari a quella richiesta (definibile in fase di configurazione). Il link per scaricare la versione installabile è qui, mentre se volete la versione contenente anche il codice sorgente la trovate qui.Ovviamente il tutto è liberamente scaricabile e modificabile. Qualsiasi suggerimento e/o modifica al codice è ben accetta!
Sperando di aver fatto cosa gradita...
Technorati Tags: TFS, Agile, CodeCoverage, TDD, UnitTest