Giornata di uno sviluppatore ALM: scrivere il nuovo codice per una storia utente

Sei un nuovo utente di Visual Studio Application Lifecycle Management (ALM) e Team Foundation Server (TFS)?Ti stai domandando come tu e il tuo team potete ottenere il massimo vantaggio dalla versioni più recenti di questi strumenti per costruire un'applicazione?

Allora dedica alcuni minuti per seguire questa esercitazione di due capitoli e seguire un giorno di vita di Peter e Julia, due sviluppatori della Fabrikam Fiber—una società fittizia che fornisce televisione via cavo e servizi correlati.Verranno visualizzati esempi su come utilizzare Visual Studio e TFS per estrarre ed aggiornare il codice, sospendere il lavoro in caso di interruzioni, richiedere una revisione di codice, archiviare le modifiche ed eseguire altre attività.

La storia finora

Il team ha recentemente cominciato ad adottare Visual Studio e Team Foundation Server per l'Application Lifecycle Management (ALM).Hanno impostato il server e i computer client, hanno creato un backlog, pianificato un'iterazione e completato altre pianificazioni necessarie per avviare lo sviluppo della propria applicazione.

Panoramica su questo capitolo

Peter brevemente rivede il suo backlog e seleziona l'attività su cui lavorerà oggi.Scrive unit test per il codice che intende sviluppare.In genere, esegue i test più volte in un'ora, scrivendo gradualmente test più dettagliati e scrivendo il codice per passarli.Discute spesso l'interfaccia del codice con i colleghi che utilizzaranno il metodo che sta scrivendo.

[!NOTA]

Le funzionalità Lavoro Personale e Code Coverage che sono descritte in questo argomento sono disponibili solo in Visual Studio Premium e in Visual Studio Ultimate.

In questo argomento

• Rivedere il backlog personale e preparare le attività per iniziare a lavorare

• Creare il primo unit test

• Creare uno stub per il nuovo codice

• Eseguire il primo test

• Accettare l'api

• Rosso, verde, Refactoring…

• Code coverage

• Quando abbiamo finito?

• Archiviare le modifiche

Rivedere il backlog personale e preparare le attività per iniziare a lavorare

In Team Explorer, Peter apre la pagina Lavoro personale.Il team ha deciso che, durante lo sprint corrente, Peter lavorerà sullo stato di valutazione della fattura, un elemento con alta priorità nel backlog del prodotto.Peter decide di iniziare con l'implementazione delle funzioni matematiche, un'attività figlio dell'elemento con alta priorità del backlog.Trascina questa attività dall'elenco Elementi di lavoro disponibili nell'elenco Modifiche ed elementi di lavoro in corso.

Per rivedere il backlog personale e preparare le attività per iniziare a lavorare

1. In Team Explorer:

   1. Se non si è già connessi al progetto team con cui si desidera lavorare, connettersi al progetto team.

   2. Scegliere Home e quindi Lavoro personale.

2. Nella pagina Lavoro personale, trascinare l'attività dall'elenco Elementi di lavoro disponibili alla sezione Elementi di lavoro in corso.

   È inoltre possibile selezionare un'attività nell'elenco Elementi di lavoro disponibili e quindi scegliere Avvia.

Bozza del piano di lavoro incrementale

Peter sviluppa in genere il codice in una serie di piccoli passaggi.Ogni passaggio in genere richiede non più di un'ora e potrebbe anche solo dieci minuti.In ogni fase, scrive un nuovo unit test e modifica il codice in fase di elaborazione in modo che superi il nuovo test, oltre ai test già impiegati.Talvolta scrive il nuovo test prima di modificare il codice e talvolta modifica il codice prima della scrittura del test.Talvolta effettua il refactoring.Ovvero migliora solo il codice senza aggiungere nuovi test.Non modifica mai un test che passa, a meno che non rappresenti correttamente un requisito.

Alla fine di ogni piccolo passaggio, esegue tutti gli unit test pertinenti a questa area del codice.Non considera il passaggio completo finchè non ha passato tutti i test.

Tuttavia, non depositerà il codice in Team Foundation Server prima del completamento dell'intera attività.

Peter annota un piano approssimativo per questa sequenza di piccoli passaggi.Riconosce che i dettagli e l'ordine esatti dei successivi probabilmente cambieranno il suo modo di lavorare.Di seguito è riportato il suo elenco iniziale dei passaggi per questa particolare attività:

1. Creare il metodo di test stub—ovvero solo la firma del metodo.

2. Soddisfare un caso tipico specifico.

3. Testare l'intervallo ampio.Assicurarsi che il codice risponda correttamente ad un ampio insieme di valori.

4. Eccezione in negativo.Testare con parametri non corretti.

5. Code coverage.Assicurarsi che almeno l'80% del codice sia esercitata dalle unit test.

Alcuni dei suoi colleghi scrivono questo tipo di piano in commenti nel loro codice di test.Altri semplicemente memorizzano il loro piano.Peter ritiene utile scrivere il proprio elenco dei passaggi nel campo Descrizione dell'elemento di lavoro dell'attività.Se deve passare temporaneamente a un'attività più urgente, sa dove trovare l'elenco quando sarà in grado di ritornarci.

Creare il primo unit test

Peter inizia creando un unit test.Egli inizia con lo unit test perché desidera scrivere un esempio di codice che utilizza la sua nuova classe.

Si tratta del primo unit test per la libreria di classi che deve testare, quindi crea un nuovo progetto di unit test.Apre la finestra di dialogo Nuovo progetto e sceglie Visual c#, Test e quindi Progetto Unit Test.

Il progetto unit test fornisce un file C# in cui lui può scrivere il suo esempio.In questa fase, desidera semplicemente illustrare come uno dei suoi nuovi metodi verrà richiamato:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Fabrikam.Math.UnitTest
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        // Demonstrates how to call the method.
        public void SignatureTest()
        {
            // Create an instance:
            var math = new Fabrikam.Math.LocalMath();

            // Get a value to calculate:
            double input = 0.0;

            // Call the method:
            double actualResult = math.SquareRoot(input);

            // Use the result:
            Assert.AreEqual(0.0, actualResult);
        }
    }
}

Lui scrive l'esempio in un metodo di test poichè, dal momento in cui ha scritto il codice, vuole che l'esempio funzioni.

Per creare un progetto unit test e i metodi

In genere è necessario creare un nuovo progetto di test per ogni progetto da testare.Se esiste già un progetto di test, è sufficiente aggiungere le nuove classi e i nuovi metodi di prova.

Questa procedura utilizza il Visual Studio Unit Test Framework ma è anche possibile utilizzare i framework di altri provider.L'Esplora test funziona in modo corretto anche con altri framework, se si installa l'adattatore appropriato.

• Creare un progetto test se non esiste già.

  • Nella finestra di dialogo Nuovo progetto, scegliere un linguaggio come Visual Basic, Visual C++ o Visual C#.Scegliere Test e poi Progetto unit test.

• Aggiungere i test per la classe test fornita.Ogni unit test è un metodo.

  Ogni unit test deve essere preceduto dall'attributo TestMethod e il metodo di unit test non dovrebbe ricevere parametri.È possibile utilizzare qualsiasi nome desiderato per un metodo unit test:

          [TestMethod]
          public void SignatureTest()
          {...}
  

      <TestMethod()>
      Public Sub SignatureTest()
      ...
      End Sub
  

• Ogni metodo di test deve chiamare un metodo della classe Assert, per indicare se viene superato o non superato.In genere, si verifica che i risultati previsti ed effettivi di un'operazione sono uguali:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• I metodi di test possono chiamare altri metodi comuni che non presentano l'attributo TestMethod.

• È possibile organizzare i test in più di una classe.Ogni classe deve essere preceduta dall'attributo TestClass.

  [TestClass]
  public class UnitTest1
  { ... }
  

  <TestClass()>
  Public Class UnitTest1
  ...
  End Class
  

Per ulteriori informazioni su come scrivere unit test in C++, vedere Scrittura di unit test per C/C++ con il framework unit test di Microsoft per C++..

Creare uno stub per il nuovo codice

Successivamente, Peter crea un progetto libreria di classi per il suo nuovo codice.Ora esiste un progetto per il codice in fase di sviluppo e un progetto di unit test.Aggiunge un riferimento di progetto dal progetto di test al codice in fase di sviluppo.

Nel nuovo progetto, ha aggiunto la nuova classe e una versione ridotta del metodo che consente almeno al test compilare correttamente.La modalità più rapida per farlo è di generare una classe e un metodo stub dalla chiamata nel test.

        public double SquareRoot(double p)
        {
            throw new NotImplementedException();
        }

Per generare classi e metodi dai test

Per prima cosa, creare il progetto in cui si desidera aggiungere la nuova classe, a meno che non esista già.

Per generare una classe

1. Posizionare il cursore su un esempio della classe che si desidera generare, ad esempio, LocalMath.Scegliere dal menu di scelta rapida Genera codice, Nuovo tipo.

2. Nella finestra di dialogo Nuovo tipo, impostare Progetto con progetto libreria di classi.In questo esempio è Fabrikam.Math.

Per generare un metodo.

• Posizionare il cursore su una chiamata al metodo, ad esempio, SquareRoot.Scegliere dal menu di scelta rapida Genera codice, Metodo stub.

Eseguire il primo test

Peter genera ed esegue il test premendo CTRL+R, T.Il risultato del test mostra un indicatore di fallimento rosso e il test verrà visualizzato nell'elenco Test non superati.

Effettua una semplice modifica al codice:

       public double SquareRoot(double p)
        {
            return 0.0;
        }

Esegue nuovamente il test e lo passa:

Per eseguire unit test

• Dal menu Test, scegliere Esegui, Tutti i test.

  - oppure -

• Se l'Esplora Test è aperto, scegliere Esegui tutto.

  - oppure -

• Posizionare il cursore in un file di codice di test e premere CTRL+R, T.

• Se un test viene visualizzato in Test non superati:

  Aprire il test, ad esempio, facendo doppio clic sul nome.

  Viene mostrato il punto in cui il test ha fallito.

Per visualizzare un elenco completo di test, scegliere Mostra tutto.Per tornare al riepilogo, scegliere la visualizzazione PAGINA INIZIALE.

Per visualizzare i dettagli del risultato di un test, selezionare il test in Esplora test.

Per spostarsi all'interno del codice di un test, fare doppio clic sul test in Test Explorer, o scegliere Apri test nel menù di scelta rapida.

Per eseguire il debug di un test, aprire il menù di scelta rapida per uno o più test, quindi scegliere Debug test selezionati.

Per eseguire test in background ogni volta che si compila la soluzione, attivare/disattivare Esegui test dopo la compilazione.Vengono eseguiti per primi i test che precedentemente hanno fallito.

Accettare l'interfaccia

Peter chiama la sua collega Julia su Lync e condivide il suo schermo.Lei utilizzerà il suo componente.Lui le mostra il suo esempio iniziale.

Julia pensa che l'esempio sia OK, ma commenta, "Molte funzioni passerebbero quel test."

Peter risponde, "Il primo test è solo per assicurarsi che il nome ed i parametri della funzione siano corretti.Ora possiamo scrivere un test che acquisisce il requisito principale di questa funzione."

Insieme scrivono il test seguente:

  
      [TestMethod]
        public void QuickNonZero()
        {
            // Create an instance to test:
            LocalMath math = new LocalMath();

            // Create a test input and expected value:
            var expectedResult = 4.0;
            var inputValue = expectedResult * expectedResult;

            // Run the method:
            var actualResult = math.SquareRoot(inputValue);

            // Validate the result:
            var allowableError = expectedResult/1e6;
            Assert.AreEqual(expectedResult, actualResult, allowableError,
                "{0} is not within {1} of {2}", actualResult, allowableError, expectedResult);
        }

Suggerimento

Per questa funzione, Peter sta utilizzando il Test First Development, in cui egli prima scrive lo unit test per una funzionalità e poi scrive codice che soddisfa il test.In altri casi, trova che questa operazione non sia reale, pertanto, scrive i test dopo aver scritto il codice.Ma considera molto importante scrivere unit test—prima o dopo aver scritto il codice—perché mantengono il codice stabile.

Rosso, verde, Refactoring…

Peter segue un ciclo in cui scrive ripetutamente un test e verifica che fallisce, scrive il codice per superare il test e poi considera il refactoring—che è, aggiornare il codice senza modificare i test.

Rosso

Peter preme CTRL + R, T per eseguire il nuovo test che ha creato con Julia.Dopo che scrive il test, lo esegue sempre per verificare che fallisca prima di scrivere il codice che permette di superarlo.Questa è una pratica che ha imparato dopo aver dimenticato di inserire le asserzioni in alcuni test che ha scritto.Vedere il risultato sbagliato gli fornisce la fiducia che quando lo supera, il risultato del test corretto indica che un requisito è stato soddisfatto.

Un'altra operazione utile è di impostare Esegui test dopo compilazione.Questa opzione esegue i test in background ogni volta che si compila la soluzione, in modo da consentire un rapporto continuo dello stato del test del codice.Peter all'inizio sospettava che questo potesse rendere Visual Studio più lento a rispondere, ma si rende conto che questo capita raramente.

Verde

Peter scrive il primo tentativo di codice del metodo che sta sviluppando:

    public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate;
                estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }
        

Peter esegue di nuovo i test e tutti questi vengono superati:

Refactoring del codice

Ora che il codice esegue la sua funzione principale, Peter lo esamina per cercare di migliorarne le prestazioni, o per rendere più semplice modificarlo in futuro.Si rende conto che può ridurre il numero di calcoli eseguiti nel ciclo:

public class LocalMath
    {
        public double SquareRoot(double x)
        {
            double estimate = x;
            double previousEstimate = -x;
            while (System.Math.Abs(estimate - previousEstimate) > estimate / 1000)
            {
                previousEstimate = estimate; 
                estimate = (estimate + x / estimate) / 2;
                //was: estimate = (estimate * estimate - x) / (2 * estimate);
            }
            return estimate;
        }

Verifica che i test vengano superati ancora:

Suggerimento

Ogni modifica apportata mentre si sviluppa il codice deve essere un refactoring o un'estensione: Refactoring significa non modificare i test perché non si stanno aggiungendo nuove funzionalità. Estensione significa aggiungere test e apportare modifiche al codice necessarie per superare sia i test nuovi sia quelli già esistenti. Se si aggiorna il codice esistente ai requisiti che sono stati modificati, vengono eliminati i test più vecchi che non rappresentano più i requisiti correnti. Evitare di modificare i test che sono già stati superati.Piuttosto, aggiungere nuovi test.Scrivere solo test che rappresentano un requisito attivo. Eseguire i test dopo ogni modifica.

… e ripetere

Peter continua la sua serie di passaggi di estensione e refactoring, utilizzando il proprio elenco di piccole operazioni come una guida approssimativa.Egli non esegue sempre un passo di refactoring dopo ogni estensione e talvolta esegue più di un passaggio di refactoring in successione.Ma esegue sempre gli unit test dopo ogni modifica al codice.

Talvolta aggiunge un test che non richiede alcuna modifica al codice, ma questo aggiunge fiducia sul fatto che il suo codice funzioni correttamente.Ad esempio, egli intende verificare che la funzione lavori su una vasta gamma di input.Scrive ulteriori test, come questo:

        [TestMethod]
        public void SqRtValueRange()
        {
            LocalMath math = new LocalMath();
            for (double expectedResult = 1e-8;
                expectedResult < 1e+8;
                expectedResult = expectedResult * 3.2)
            {
                VerifyOneRootValue(math, expectedResult);
            }
        }
        private void VerifyOneRootValue(LocalMath math, double expectedResult)
        {
            double input = expectedResult * expectedResult;
            double actualResult = math.SquareRoot(input);
            Assert.AreEqual(expectedResult, actualResult, expectedResult / 1e6);
        }

Questo test viene superato la prima volta che viene eseguito:

Solo per assicurarsi che questo risultato non è un errore, introduce temporaneamente un piccolo errore nel test per farlo fallire.Dopo aver assistito all'errore, lo risolve nuovamente.

Suggerimento
Sempre far fallire un test prima di passarlo.

Eccezioni

Peter passa ora alla scrittura di test per input eccezionali:

[TestMethod]
        public void RootTestNegativeInput()
        {
            LocalMath math = new LocalMath();
            try
            {
                math.SquareRoot(-10.0);
            }
            catch (ArgumentOutOfRangeException)
            {
                return;
            }
            catch
            {
                Assert.Fail("Wrong exception on negative input");
                return;
            }
            Assert.Fail("No exception on negative input");
        }

Questo test inserisce il codice in un ciclo.Deve utilizzare il pulsante Annulla in Esplora Test.Questo termina il codice entro 10 secondi.

Peter desidera assicurarsi che un ciclo infinito non si verifichi sul server di compilazione.Anche se il server impone un timeout su un'esecuzione completa, è un timeout molto lungo e causerebbe un sostanziale ritardo.Di conseguenza, ha aggiunto un timeout esplicito per questo test:

        [TestMethod, Timeout(1000)]
        public void RootTestNegativeInput()
        {...

Il timeout esplicito fa fallire il test.

Peter aggiorna quindi il codice per far fronte a questo caso eccezionale:

       public double SquareRoot(double x)
        {
            if (x <= 0.0) 
            {
                throw new ArgumentOutOfRangeException();
            }

Regressione

Il nuovo test ha esito positivo, ma c'è una regressione.Un test passato in precedenza ora fallisce:

Peter individua e corregge l'errore:

      public double SquareRoot(double x)
        {
            if (x < 0.0)  // not <=
            {
                throw new ArgumentOutOfRangeException();
            }

Dopo averlo corretto, tutti i test vengono superati:

Suggerimento
Verificare che tutti i test vengano superati dopo ogni modifica fatta al codice.

Code coverage

A intervalli regolari durante il lavoro e prima di controllare nel codice, Peter ottiene un rapporto code coverage.Questo mostra la quantità di codice che è stato esercitato dai suoi test.

Il team di Peter ha lo scopo coprire almeno l'80%.Riducono questo requisito al codice generato, poiché può essere difficile ottenere una copertura elevata per questo tipo di codice.

Una buona coverage non garantisce che la funzionalità completa del componente sia stata testata e non garantisce che il codice venga eseguito per qualsiasi valore in input.Tuttavia, esiste una correlazione abbastanza stretta tra il coverage delle righe di codice e il coverage dello spazio comportamentistico di un componente.Di conseguenza, una buona coverage consolida la fiducia del team che stanno testando più comportamenti di quanti dovrebbero.

Per ottenere un rapporto code coverage, dal menu Test, scegliere Esegui, Analizza Code Coverage per tutti i test.Poi eseguire di nuovo tutti i test.

Peter Ottiene una copertura totale dell'86%.Quando espande il totale nel rapporto, dimostra che il codice che sta sviluppando a coperto il 100%.Ciò è particolarmente soddisfacente, poiché il punteggio importante è per il codice sotto test.Le sezioni senza code coverage sono attualmente nei test stessi.Usando il pulsante Mostra colorazione code coverage, Peter può verificare quali parti del codice di test non sono state verificate.Tuttavia, stabilisce che queste sezioni non sono rilevanti per il coverage poichè si trovano nel codice di test e verranno utilizzate solo se viene rilevato un errore.

Per verificare che un determinato test raggiunge in branch specifici del codice, è possibile impostare Mostra colorazione Code Coverage e quindi eseguire il singolo test utilizzando il comando Esegui nel menu di scelta rapida.

Quando abbiamo finito?

Peter continua ad aggiornare il codice a piccoli passaggi finchè non è soddisfatto:

• Tutti gli unit test disponibili vengono superati.

  In un progetto con un set di unit test molto grande, per uno sviluppatore può essere opportuno aspettarli tutti per eseguire.Al contrario, il progetto opera un servizio di archiviazione gestita, in cui tutti i test automatici vengono eseguiti per ogni shelveset di archiviazione prima di essere unito all'albero di origine.L'archiviazione viene rifiutata se l'esecuzione fallisce.Ciò consente agli sviluppatori di eseguire un set minimo di unit test sul proprio computer e quindi procedere con altre attività senza rischiare di danneggiare la compilazione.Per ulteriori informazioni, vedere Definire un processo di compilazione di archiviazione gestita per convalidare le modifiche.

• Il code coverage incontra gli standard del team.il 75% è un requisito di progetto tipico.

• I suoi unit test simulano ogni aspetto del comportamento richiesto, inclusi sia gli input tipici sia quelli eccezionali.

• Il suo codice è facile da comprendere ed estendere.

Quando tutti questi criteri sono validi, Peter è pronto a controllare il codice nel controllo sorgente.

Principi di sviluppo del codice con gli unit test

Peter applica i seguenti principi durante lo sviluppo di codice:

• Compilare unit test con il codice ed eseguirli frequentemente durante lo sviluppo.Gli unit test rappresentano la specifica del componente.

• Non modificare gli unit test, a meno che non siano stati modificati i requisiti o i test siano sbagliati.Aggiungere nuovi test gradualmente come si estendono le funzionalità del codice.

• Mirare a coprire almeno il 75% del codice con i test.Esaminare i risultati di code coverage a intervalli e prima di archiviare il codice sorgente.

• Archiviare gli unit test con il codice, in modo che saranno eseguiti dalle continue o regolari compilazioni server.

• Laddove possibile, per ogni funzionalità, è necessario scrivere prima lo unit test.Eseguire questa operazione prima di sviluppare il codice che lo soddisfi.

Archiviare le modifiche

Prima di archiviare le sue modifiche, Peter utilizza ancora Lync per condividere lo schermo con la sua collega Julia così può rivedere con lui quello che ha creato in modo interattivo e senza formalità.I test continuano ad essere il centro della loro discussione perché Julia è principalmente interessata a quello che il codice fa, non come funziona.Julia si accorege che Peter ha scritto in modo da soddisfare i suoi bisogni.

Peter archivia tutte le modifiche che ha eseguito, inclusi i test e il codice e li associa all'attività che ha completato.L'archiviazione accoda il sistema automatizzato di Team Build del team per convalidare le sue modifiche utilizzando il processo di compilazione CI del team.Questo processo di compilazione consente al team di ridurre gli errori nei loro codebase compilando e testando—in un ambiente pulito separato dai loro computer di sviluppo—ogni modifica che il team fa.

Peter riceve una notifica quando la compilazione è completa.Nella finestra dei risultati di compilazione, vede che la compilazione ha avuto successo e tutti i test sono stati superati.

Per archiviare le modifiche

1. Nella barra dei menu scegliere Visualizza, Team Explorer.

2. In Team Explorer, scegliere Home , e quindi scegliere Lavoro Personale.

3. Nella pagina Lavoro Personale, scegliere Archivia.

4. Esaminare il contenuto della pagina Modifiche in sospeso per verificare che:

   • Tutte le modifiche rilevanti siano elencate in Modifiche incluse

   • Tutti gli elementi di lavoro rilevanti siano elencati in Elementi di lavoro correlati.

5. Specificare un Commento per aiutare il team a comprendere lo scopo di queste modifiche quando guardano la cronologia di controllo delle versioni dei file e delle cartelle modificate.

6. Scegliere Archivia.

Per integrare in modo continuo il codice

Per ulteriori informazioni su come definire un processo di compilazione di integrazione continua, vedere Definire un processo di compilazione per supportare l'integrazione continuata.Dopo avere installato il processo di compilazione, è possibile scegliere di ricevere una notifica sui risultati della compilazione del team.

Per ulteriori informazioni, vedere Eseguire, monitorare e gestire compilazioni.

Avanti (sospendere il lavoro, correggere un bug ed eseguire una revisione del codice)