Ein Tag im Leben eines ALM-Entwicklers: Schreiben von Code für eine User Story

Sind Sie ein neuer Benutzer der Anwendungslebenszyklus-Verwaltung (ALM) und Team Foundation Server (TFS)?Wundern Sie, wie Sie und Ihr Team maximale Vorteil von der letzten Version dieser Tools abrufen können, um die Anwendung zu erstellen?

Anschließend verwenden Sie einigen Minuten zu schrittweisem die des Gangs dieses Lernprogramm ZweiKapitel und führen Sie einen Tag in den Lebensdauer von Peter und von Julia, zwei Entwickler bei Fabrikam Fiber-ein erfundener Unternehmen, die Kabelfernsehen und verwandte Dienste bereitstellt.finden Sie Beispiele dafür, wie Sie Visual Studio und TFS, zum Aus- und Aktualisieren von Code verwenden können, enthalten Arbeit, wenn Sie unterbrochen werden, fordern eine Codeüberprüfung, checken die Änderungen und andere Aufgaben ausführen.

Die Story bis jetzt

Das Team hat kürzlich Annahme Visual Studio und Team Foundation Server für Anwendungslebenszyklus-Verwaltung (ALM).Sie ihren installierten Server und Clientcomputer erstellt haben, ein Rückstand, einer Iteration geplant, und andere abgeschlossen die Planung, die erforderlich ist, zu starten, ihre App.

Übersicht über dieses Kapitels

Peter wiederholt kurz den Rückstand und wählt die Aufgabe aus, die er an heute bearbeitet.Er schreibt Komponententests für den Code, den er plant entwickelt werden.In der Regel versieht er die Tests mehrmals in einer Stunde, allmählich schreibt detailliertere Tests und schreibt dann den Code, der sie übergeben können.Er erläutert häufig die Schnittstelle des Codes mit Kollegen, die die Methode verwenden, die, er schreibt.

Hinweis
Die My Arbeits- und Code-Abdeckungsfunktionen, die in diesem Thema behandelt werden, sind nur in Visual Studio Premium und in Visual Studio Ultimate verfügbar.

In diesem Thema

• Wiederholen Sie persönlichen Rückstand und bereiten Sie Aufgaben vor, die Arbeit zu starten

• Erstellen Sie den Test der ersten Komponententest

• Erstellen Sie einen Stub für den neuen Code erstellt

• Führen Sie den ersten Test

• Sie sollten den APIs zu

• Rot, Grün, Umgestalten...

• Codeabdeckung

• Wann werden wir ausgeführt?

• Einchecken der Änderungen

Wiederholen Sie persönlichen Rückstand und bereiten Sie Aufgaben vor, die Arbeit zu starten

In Team Explorer Peter Meine Arbeit öffnet die Seite.Das Team hat, dass, während des aktuellen Sprints, Peter an Evaluate Rechnungsstatus funktioniert, ein Hauptprioritätselement im Produktrückstand zugestimmt.Peter entscheidet, um mit Werkzeugmathematischen funktionen, eine untergeordnete Aufgabe zum Starten des Hauptprioritätsrückstandselements.Ziehen Sie diese Aufgabe aus der Liste Verfügbare Arbeitsaufgaben in die Liste Arbeitselemente & Änderungen in Bearbeitung.

So persönlichen Rückstand überprüfen und Aufgaben vorbereiten, Arbeit zu starten

1. In Team Explorer:

   1. Wenn Sie nicht bereits über eine Verbindung mit dem Teamprojekt verfügen, in dem Sie arbeiten möchten, stellen Sie eine Verbindung mit dem Teamprojekt her.

   2. Wählen Sie Startseite aus und wählen dann Meine Arbeit aus.

2. Klicken Sie auf der Seite Meine Arbeit ziehen Sie die Aufgabe aus der Liste Verfügbare Arbeitsaufgaben zum Laufende Arbeitsaufgaben-Abschnitt.

   Sie können eine Aufgabe in der Liste Verfügbare Arbeitsaufgaben auch auswählen und Start auswählen.

Entwurfs-inkrementeller Arbeitsplan

Peter entwickelt normalerweise Code in einer Reihe von kleinen Schritten.Jeder Schritt wird in der Regel nicht mehr als einer Stunde und könnte so wenig wie zehn Minuten.In jedem Schritt schreibt er einen neuen Komponententest und ändert den Code, den er, damit er den neuen Test führt, zusätzlich zu den Tests entwickelt, die, er bereits geschrieben hat.Manchmal schreibt er den neuen Test, bevor er den Code ändert, manchmal er ändert den Code, bevor er den Test schreibt.Manchmal umgestaltet er.Das heißt, verbessert er nur den Code, ohne neue Tests hinzuzufügen.Seine nie einen Test, der übergeben werden, es sei denn, er entscheidet, dass nicht ordnungsgemäß eine Anforderung dargestellt.

Am Ende jedes kleinen Schritts, macht es alle Komponententests, die diesem Bereich des Codes relevant sind.Es berücksichtigt den Schritt als nicht vollständig bis übergibt jedes Tests.

Allerdings überprüft er den Code nicht in Team Foundation Server, bis er die gesamte Aufgabe beendet wurde.

Peter notiert einen groben Plan für diese Sequenz von kleinen Schritten.Er weiß, dass die genauen Details und die Reihenfolge der späteren wahrscheinlich ändern, wie er funktioniert.Hier ist die ursprüngliche Liste von Schritten für die jeweilige Aufgabe:

1. Erstellen Sie Testmethode, Stub-dass ist, nur die Signatur der Methode zu.

2. Erstellen Sie einen typischen Fall der spezifischen erfüllt.

3. Testen Sie eine Reihe.Stellen Sie sicher, dass der Code ordnungsgemäß auf einen großen Wertebereich reagiert.

4. Ausnahme auf null.Daten ordnungsgemäß mit falschen Parameter.

5. Codeabdeckung.Stellen Sie sicher, dass mindestens 80% des Codes durch Komponententests ausgeführt wird.

Einige Kollegen schreiben diese Art des Plans in Kommentaren in ihrem Testcode.Andere derzeit merken sich ihren Plan.Peter sucht es hilfreich sein, die Liste von Schritten im Textfeld der Arbeitsaufgabe zu schreiben.Wenn sie auf einer dringenderen Aufgabe vorübergehend wechseln, muss er weiß, wo die Liste sucht, wenn er in der Lage ist, in den zurückzukehren.

Erstellen Sie den Test der ersten Komponententest

Peter beginnt, indem er einen Komponententest erstellt.Er beginnt mit dem Komponententest, da er ein Beispiel des Codes schreiben möchte, der die neue Klasse verwendet.

Dies ist der Test der ersten Komponententest für die Klassenbibliothek, dass er testet, daher wird ein neuer erstellt Komponententestprojekt.Er öffnet das Dialogfeld Neues Projekt und wählt Visual C#, Test und dann Komponententestprojekt aus.

Das Komponententestprojekt stellt eine C#-Datei, in der er sein Beispiel schreiben kann.In dieser Phase möchte er gerade veranschaulichen, wie eine seiner neuen Methoden aufgerufen wird:

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);
        }
    }
}

Er schreibt das Beispiel in einer Testmethode, da, bis er den Code geschrieben hat, er das Beispiel arbeiten wünscht.

So fügen Sie ein Komponententestprojekt und Methoden erstellen

Normalerweise würden Sie ein neues Testprojekt für jedes Projekt erstellen, das getestet wird.Wenn ein Testprojekt bereits vorhanden ist, können Sie neue Testmethoden und Klassen nur hinzufügen.

Diese Prozedur verwendet das Visual Studio-Komponententestframework, aber Sie können Frameworks von anderen Anbietern auch verwenden.Test-Explorer funktioniert gleichermaßen gut mit anderen Frameworks, sofern Sie den entsprechenden Adapter installieren.

• Erstellen Sie ein Testprojekt, falls nicht vorhanden.

  • Im Dialogfeld Neues Projekt wählen Sie eine Sprache wie Visual Basic, Visual C++ oder Visual C# aus.Wählen Sie Test und dann Komponententestprojekt aus.

• Fügen Sie die Tests der Testklasse hinzu, die bereitgestellt wird.Jeder Komponententest ist eine Methode.

  Jeder Komponententest muss vom TestMethod-Attribut vorangestellt wird, und die Komponententestmethode sollte keine Parameter haben.Sie können einen beliebigen Namen verwenden, den Sie für eine Komponententestmethode möchten:

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

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

• Jede Testmethode sollte eine Methode der Klasse aufrufen Assert um anzugeben, ob sie erfolgreich oder fehlerhaft ist.In der Regel stellen Sie sicher, dass die erwarteten und tatsächlichen Ergebnisse eines Vorgangs gleich sind:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Testmethoden können andere gewöhnliche Methoden aufrufen, die TestMethod nicht das Attribut verfügen.

• Sie können die Tests in mehr als eine Klasse organisieren.Jede Klasse muss vom TestClass-Attribut vorangestellt wird.

  [TestClass]
  public class UnitTest1
  { ... }
  

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

Weitere Informationen dazu, wie Sie Komponententests in C++, finden Sie unter Schreiben von Komponententests für C/C++ mit dem Microsoft-Komponententestframework für C++ schreibt.

Erstellen Sie einen Stub für den neuen Code erstellt

Als Nächstes erstellt Peter ein Klassenbibliotheksprojekt für den neuen Code.Es gibt jetzt ein Projekt für den Code in der Entwicklung und ein Projekt für die Komponententests.Es fügt einen Projektverweis aus dem Testprojekt dem Code in der Entwicklung hinzu.

im neuen Projekt werden die neue Klasse und eine minimale Version der Methode hinzu, die mindestens dem Test ermöglicht, erfolgreich zu erstellen.Die schnellste Methode durch, die, einen Klassen- und Methodenstub vom Aufruf im Test zu generieren ist.

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

Wenn Sie Klassen und Methoden von Tests generieren

Erstellen Sie zuerst das Projekt, in dem Sie die neue Klasse hinzufügen möchten, es sei denn, sie bereits vorhanden ist.

Um eine Klasse generieren

1. Platzieren Sie den Cursor in einem Beispiel der Klasse, die Sie beispielsweise LocalMath generieren möchten.Klicken Sie im Kontextmenü wählen Sie Code generieren, Neuer Typ aus.

2. Im Dialogfeld Neuer Typ legen Sie Projekt auf das Klassenbibliotheksprojekt fest.In diesem Beispiel ist es Fabrikam.Math.

So fügen Sie eine Methode generieren

• Platzieren Sie den Cursor in einem Aufruf der Methode beispielsweise SquareRoot.Klicken Sie im Kontextmenü wählen Sie Code generieren, Methodenstub aus.

Führen Sie den ersten Test

Peter erstellt und der Test ausgeführt wird, indem er STRG+R, T drückt.Das Testergebnis zeigt einen roten fehlerhafte Indikator an und der Test wird unter der Liste der Fehlgeschlagene Tests.

Er besitzt eine einfache Änderungen am Code vornehmen:

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

Es macht den Test erneut und die enthaltenen:

Um den Komponententests

• Klicken Sie im Menü Test wählen Sie Ausführen, Alle Tests aus.

  - oder -

• Wenn Test-Explorer geöffnet ist, wählen Sie Alle ausführen aus.

  - oder -

• Platzieren Sie den Cursor in einer Testcodedatei und in einer STRG+R, T drücken.

• Wenn ein Test mit Fehlgeschlagene Tests angezeigt:

  Öffnen Sie den Test indem Sie beispielsweise auf den Namen doppelklicken.

  Der Punkt, an dem der Test fehlgeschlagen ist, wird angezeigt.

So fügen Sie eine vollständige Liste der Tests sehen, wählen Alle anzeigen aus.Um zur Zusammenfassung zurückzukehren, wählen Sie die Ansicht Startseite.

Um die Details eines Testergebnisses finden, wählen den Test im Test-Explorer aus.

Um den Code eines Tests navigieren, Doppelklick der Test im Test-Explorer oder Test öffnen wählen im Kontextmenü aus.

Um einen Test debuggen, öffnen das Kontextmenü für eine oder mehrere Tests und wählen dann Ausgewählte Tests debuggen aus.

So führen Sie Tests im Hintergrund ausführen, wenn Sie die Projektmappe erstellen, Umschaltfläche Nach dem Buildvorgang Tests ausführen.Tests, die zuvor fehlgeschlagen zuerst ausgeführt werden.

Sie sollten der Schnittstelle zu

Peter ruft ihren Kollegen Julia auf Lync auf und gibt den Bildschirm frei.Sie wird die Komponente verwenden.Sie zeigt sein ursprüngliche Beispiel.

Julia erstellen möchten, dass das Beispiel OK ist, jedoch Kommentare, "viele Funktionen übergeben würden, dass Test".

Peter antwortet, "der erste Test ist einfach, zu überprüfen, ob der Name und die Parameter der Funktion korrekt sind.Nun können Sie einen Test schreiben, der für die zentrale Anforderung dieser Funktion".

Zusammen schreiben sie den folgenden Test:

  
      [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);
        }

Tipp

Für diese Funktion verwendet Peter Test-First-Entwicklung, in der sie zuerst den Komponententest für eine Funktion schreibt, und schreibt Code, der den Test erfüllt.In anderen Fällen sucht es, dass diese Vorgehensweise nicht, sodass stattdessen, er schreibt die Tests realistischer ist, nachdem er den Code schreibt.Aber betrachtet er es als sehr wichtig, Einheit zu schreiben Test-ob vor oder nach, Code-weil sie den Code stabil bleiben.

Rot, Grün, Umgestalten...

Peter folgt einem Zyklus, in dem er wiederholt einen Test schreibt und bestätigt, dass nicht kann, wird Code die Tests ausführen und dann betrachtet, Umgestaltung-dass ist und den Code verbessert, ohne die Tests zu ändern.

Rot

STRG+R, T Peter drückt, um den neuen Test auszuführen, den er mit Julia erstellt hat.Nachdem Sie einen Test schreibt, er immer ausgeführt wird, um sicherzustellen, dass es fehlschlägt, bevor er den Code, der übergeben können.Dies ist üblich, das er lernte, nachdem er vergisst, Assertionen in einigen Tests zu platzieren er geschrieben hat.Das Anzeigen des Fehlerergebnisses gibt dieser Vertrauen, das, wenn sie übergeben können, das Testergebnis ordnungsgemäß angibt, dass eine Anforderung erfüllt geladen wurde.

Eine weitere nützliche Praxis ist, Nach dem Buildvorgang Tests ausführen festzulegen.Diese Option werden die Tests im Hintergrund, wenn Sie die Projektmappe erstellen, damit Sie einen ständigen Bericht des Teststatus des Codes verfügen.Peter war an erstem misstrauischem, das sie Visual Studio langsam reagieren lässt, aber er sucht, dass dies selten geschieht.

Grün

Peter schreibt den ersten Versuch am Code der Methode, die er entwickelt:

    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 führt die Tests erneut und alle Tests aus:

Umgestaltung

Da der Code die Hauptfunktion ausführt, berücksichtigt Peter den Code, um Wege der Durchführung er eine bessere Leistung zu suchen, oder es einfacher zu machen, in der Zukunft zu ändern.Er stellt fest, dass er die Anzahl der Berechnungen reduzieren kann, die in der Schleife ausgeführt werden:

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;
        }

Sie überprüft, dass die Tests noch übergeben:

Tipp

Jede Änderung, die Sie vornehmen, während Sie den Code sollten entweder eine Umgestaltung oder eine Erweiterung sein entwickeln: Das Umgestaltung bedeutet, dass Sie nicht die Tests ändern, da Sie keine neuen Funktionen hinzufügen. Erweiterung bedeutet das Hinzufügen von Tests und das Durchführen der Codeänderungen, die erforderlich sind, um die vorhandenen und neuen Tests zu übergeben. Wenn Sie vorhandenen Code zu Anforderungen aktualisieren, die sich geändert haben, löschen Sie auch alte Tests, die nicht mehr die aktuellen Anforderungen darstellen. Vermeiden Sie, Tests zu ändern, die bereits bestanden wurden.Stattdessen fügen Sie neue Tests hinzu.Schreiben Sie nur Tests, die eine echte Anforderung darstellen. Erstellen Sie den Tests jede Änderung nach.

... und Wiederholung

Peter setzt die Reihe Extensions und Umgestaltungsschritte, mit der Liste der kleinen Schritten als Faustregel fort.Er nicht immer führt einen Umgestaltungsschritt nach jeder Erweiterung aus, und es wird manchmal mehr als einen umgestaltenden Schritt nacheinander aus.Aber der Ausführung immer den Komponententests jede Änderung am Code nach.

Manchmal wird er einen Test hinzu, der keine Änderungen am Code erfordert, der ihrem Vertrauen hinzufügt, dass der Code ordnungsgemäß funktioniert.Beispielsweise möchte er überprüfen, ob die Funktion über einem großen Spektrum von Eingaben funktioniert.Es gibt weitere Tests, wie dieser:

        [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);
        }

übergibt dieses Tests, wenn sie zum ersten Mal ausgeführt wird:

, sich dieses Ergebnis nur zu vergewissern ist kein Fehler, er führt vorübergehend einen kleinen Fehler in den Test, um diesen Fehler zu lassen.Nachdem der Fehler erkannt hat, behoben sie erneut.

Tipp
Lassen Sie immer einen Test fehlschlagen, bevor Sie ihn übergeben können.

Ausnahmen

Peter zieht jetzt mit dem Schreiben von Tests für Ausnahme Eingaben um:

[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");
        }

Dieser Test wird der Code in einer Schleife.Er muss die Schaltfläche Abbrechen im Test-Explorer verwenden.Dadurch wird der Code innerhalb von 10 Sekunden.

möchte Peter überprüfen, ob eine Endlosschleife nicht auf dem Buildserver passieren kann.Obwohl der Server ein Timeout einer vollständigen Ausführung gelten, ist es ein sehr langes Timeout und würde erheblichen Verzögerung verursachen.Daher wird er ein explizites Timeout diesem Test hinzu:

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

Das explizite Timeout kann der Versuch fehlschlagen.

Peter aktualisiert dann den Code, um diesen Sonderfall zu verarbeiten:

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

Regression

Die neuen Test wird erfolgreich ausgeführt, aber es eine Regression.Ein Test, der verwendete, um jetzt zu übergeben, schlägt fehl:

Peter-Suchen und -Fix der Fehler:

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

Nachdem er korrigiert wurde, die alle Tests:

Tipp
Stellen Sie sich jedes der vollständige Testdurchläufe nach jeder Änderung, die Sie am Code vornehmen.

Codieren Sie Abdeckung

In Abständen während der Arbeit und schließlich, bevor er in den Code überprüft, erhält Peter ein Bericht "Codeabdeckung".Dies zeigt an, welcher Anteil des Codes durch seine Tests ausgeführt wurde.

Peters Team strebt Abdeckung von mindestens 80% an.Sie weniger streng gehandhabt sich diese Anforderung für generierten Code, da es schwierig sein kann, eine hohe Codeabdeckung für diesen Typ des Codes zu erreichen.

Gute Codeabdeckung ist keine Garantie, dass die vollständige Funktionalität der Komponente getestet wurde, und sie garantiert nicht, dass der Code für jeden Bereich von Eingabewerten funktioniert.Trotzdem, gibt es eine relativ neben Korrelation zwischen Abdeckung von Codezeilen und Abdeckung des Verhaltensleerzeichens einer Komponente.Daher unterstützt gute Codeabdeckung das Vertrauen des Teams, dass die meisten des Verhaltens testen, das sie sollten.

Um einen Codeabdeckungsbericht, über das Menü Tests abzurufen, wählen Sie Ausführen, Codeabdeckung für alle Tests analysieren.Führen Sie dann alle Tests neu.

Peter ruft eine gesamte Abdeckung von 86%.Wenn die Summe im Bericht erweitert, stellt er dar, dass der Code, den er entstanden, Abdeckung von 100% verfügt.Dies ist sehr zufrieden stellend, da das wichtige Ergebnis für den getesteten Code ist.Die freigelegten Abschnitte sind tatsächlich in den Test selbst.Durch die Schaltfläche Codeabdeckungsfärbung anzeigen umschaltet, kann Peter finden, welche Teile des Testcodes nicht getestet wurden.jedoch entscheidet, dass er diese Abschnitte für Abdeckung unbedeutend sind, da sie im Testcode sind und nur verwendet werden, wenn ein Fehler erkannt wird.

Um sicherzustellen dass ein bestimmter Test in bestimmte Codeverzweigungen erreicht, können Sie Codeabdeckungsfärbung anzeigen festlegen und den einzelnen Test ausführen Ausführen mit dem Befehl im Kontextmenü verwenden.

Wann werden wir ausgeführt?

Folgendes wird fortgesetzt, um den Code in kleinen Schritten zu aktualisieren, bis er erfüllt ist, dass:

• Die gesamte verfügbare Komponententests bestanden.

  In einem Projekt mit einem sehr großen Satz von Komponententests, kann es für einen Entwickler nicht möglich sein, alle darauf zu warten, um ausgeführt zu werden.Stattdessen wird das Projekt einen Dienst für abgegrenzte Eincheckvorgänge, in der alle automatisierten Tests für jedes eingecheckte Shelveset ausgeführt werden, bevor es in die Zielstruktur zusammengeführt wird.Das Einchecken wird abgelehnt, wenn die Ausführung fehlschlägt.Dies ermöglicht es dem Entwickler, um einen minimalen Satz von Komponententests auf dem eigenen Computer ausführen und anschließend mit anderer Aufgaben fortfahren, ohne das Risiko des Anwendungsverhalten des Builds auszuführen.Weitere Informationen finden Sie unter Definieren eines abgegrenzten Eincheckbuildprozesses zur Überprüfung der Änderungen.

• Codeabdeckung entspricht dem Standard des Teams.75% ist eine typische Projektanforderung.

• Die Komponententests simulieren jeden Aspekt des Verhaltens, das erforderlich ist, einschließlich der typischen und Ausnahmen Eingaben.

• Der Code ist einfach zu verstehen und zu erweitern.

Wenn alle diese Kriterien erfüllt, ist Peter bereit, den Code in die Quellcodeverwaltung einzuchecken.

Prinzipien der Codeentwicklung mit Komponententests

Peter wendet die folgenden Prinzipien, während das Entwickeln von Code:

• Entwickeln Sie Komponententests gemeinsam mit dem Code, und führen Sie sie während der Entwicklung häufig aus.Die Komponententests stellen die Spezifikation der Komponente dar.

• Nicht Änderungseinheitentests ausführen, es sei denn, die Anforderungen geändert haben, oder die Tests falsch waren.Fügen Sie neue Tests allmählich hinzu, wie Sie die Funktionalität des Codes erweitern.

• Streben von mindestens 75% des an die Tests abgedeckt werden Code.Betrachten Sie die Codeabdeckungsergebnisse in Abständen und bevor Sie in Quellcode überprüfen.

• Überprüfen Sie die Komponententests gemeinsam mit dem Code, damit sie in die fortlaufende oder regulären Serverbuilder ausgeführt werden.

• Wo möglich, für jedes Funktion, schreiben Sie den Komponententest zuerst.Wählen Sie dazu, bevor Sie den Code entwickeln, der es erfüllt.

Einchecken der Änderungen

Vor dem in seinen Änderungen, Peter erneut Lync verwendet, um den Bildschirm mit seinem Kollegen freizugeben Julia Daher überprüft, sie kann damit informell und interaktiv überprüfen, was sie erstellt hat.Die Tests werden weiterhin, um der Fokus ihrer Diskussion sein, da Julia hauptsächlich relevant ist, an welchem Zweck nicht, wie sie funktioniert.Julia stimmt überein, dass darin, welcher Peter geschrieben hat, sie Anforderungen gilt.

Peter überprüft werden alle Änderungen, die er vorgenommen hat, einschließlich der Tests und den Code und ordnet sie mit der Aufgabe zu er abgeschlossen ist.Das Einchecken stellt das Team-Buildsystem des Teams automatisierte in die Warteschlange, um die Änderungen mithilfe des CI-Buildbuildprozesses des Teams zu überprüfen.Dieser Buildprozess hilft dem Team, Fehler in ihrer CodeBase zu minimieren, indem er erstellt und Tests-in einer unveränderten Umgebung getrennt von ihrer Entwicklung macht Computer-jede Änderung das Team.

Peter benachrichtigt wird, wenn der Build abgeschlossen wird.In den Buildergebnissen Fenster, sieht er, dass der Build erfolgreich war und alle Tests erfolgreich waren.

So machen Sie die Änderungen einchecken

1. Wählen Sie in der Menüleiste die Optionen Ansicht und Team Explorer aus.

2. In Team Explorer wählen Sie Startseite aus und wählen dann Meine Arbeit aus.

3. Klicken Sie auf der Seite Meine Arbeit wählen Sie Einchecken aus.

4. Überprüfen Sie den Inhalt der Seite Ausstehende Änderungen, um sicherzustellen, dass:

   • Alle relevanten Änderungen werden in Eingeschlossene Änderungen aufgeführt

   • Alle relevanten Arbeitsaufgaben werden in Verknüpfte Arbeitsaufgaben aufgeführt.

5. Geben Sie Kommentar an, die das Team helfen, den Zweck dieser Änderungen zu verstehen, wenn sie den Versionskontrollverlauf der geänderten Dateien und Ordner berücksichtigen.

6. Wählen Sie Einchecken aus.

So fügen Sie den Code fortlaufend integrieren

Weitere Informationen dazu, wie Sie einen fortlaufenden Integrationsbuildprozess, finden Sie unter Definieren eines Buildprozesses zur Unterstützung der fortlaufenden Integration definiert.Nachdem Sie diesen Buildprozess installiert haben, können Sie festlegen, über die Ergebnisse der Teambuilds benachrichtigt zu werden.

Weitere Informationen finden Sie unter Ausführen, Überwachen und Verwalten von Builds.

Als Nächstes (Halten Sie Arbeiten an, reparieren Sie einen Fehler und leiten Sie eine Codeüberprüfung)