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

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Visual Studio 2019 | Visual Studio 2022

In diesem Tutorial erfahren Sie, wie Sie und Ihr Team die neuesten Versionen von Team Foundation-Versionskontrolle (TFVC) und Visual Studio optimal nutzen können, um Ihre App zu erstellen. Das Tutorial enthält Beispiele dafür, wie Sie Visual Studio und TFVC zum Auschecken und Aktualisieren von Code, zum Anhalten der Arbeit bei Unterbrechungen, zum Anfordern eines Codereviews, zum Einchecken der Änderungen und zum Durchführen weiterer Aufgaben verwenden können.

Wenn ein Team Visual Studio und TFVC zum Verwalten seines Codes einführt, richtet es seine Server- und Clientcomputer ein, erstellt ein Backlog, plant eine Iteration und führt weitere Planungen durch, die für die Entwicklung der App erforderlich sind.

Entwickler überprüfen ihre Backlogs, um Aufgaben auszuwählen, die bearbeitet werden sollen. Sie schreiben Komponententests für den Code, deren Entwicklung sie planen. In der Regel führen sie die Tests mehrmals pro Stunde durch, schreiben dann nach und nach detailliertere Tests und anschließend den Code für den erfolgreichen Abschluss der Tests. Entwickler besprechen ihre Codeschnittstellen häufig mit Kollegen, die die von ihnen geschriebene Methode verwenden.

Die Tools Meine Arbeit und Code Review von Visual Studio unterstützen Entwickler bei der Verwaltung ihrer Arbeit und der Zusammenarbeit mit Kollegen.

Hinweis

Die Features Meine Arbeit und Code Review von Visual Studio sind mit den folgenden Editionen verfügbar:

• Visual Studio 2022: Visual Studio Community, Visual Studio Professional und Visual Studio Enterprise
• Visual Studio 2019: Visual Studio Community, Visual Studio Professional und Visual Studio Enterprise

Überprüfen von Arbeitselementen und Vorbereiten der Arbeit

Das Team hat sich darauf geeinigt, dass Sie während des aktuellen Sprints an dem Element Rechnungsstatus auswerten arbeiten, das die höchste Priorität im Product Backlog hat. Sie entscheiden sich, mit Mathematische Funktionen implementieren zu beginnen, einer dem Element mit der höchsten Priorität im Product Backlog untergeordneten Aufgabe.

In Visual Studio Team Explorer ziehen Sie auf der Seite Meine Arbeit diese Aufgabe aus der Liste Verfügbare Arbeitselemente in die Liste In Bearbeitung.

Überprüfen Ihres Backlogs und Vorbereiten der Aufgaben zum Starten der Arbeit

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

2. Wählen Sie auf der Startseite die Option Meine Arbeit aus.

3. Ziehen Sie auf der Seite Meine Arbeit die Aufgabe aus der Liste Verfügbare Arbeitselemente in den Abschnitt In Bearbeitung.

   Sie können die Aufgabe auch in der Liste Verfügbare Arbeitselemente auswählen und dann auf Start klicken.

Entwurf eines inkrementellen Arbeitsplans

Bei der Entwicklung von Code gehen Sie in der Regel schrittweise vor. Normalerweise dauert jeder Schritt zwischen 10 Minuten und einer Stunde. In jedem Schritt schreiben Sie einen neuen Komponententest und ändert den entwickelten Code so, dass zusätzlich zu den bereits geschriebenen Tests auch der neue Test bestanden wird. Manchmal schreiben Sie den neuen Test, bevor Sie den Code ändern, und manchmal ändern Sie den Code, bevor Sie den Test schreiben. Manchmal gestalten Sie alles um. Das bedeutet, dass Sie lediglich den Code optimieren, ohne neue Tests hinzuzufügen. Sie ändern niemals einen bestandenen Test, es sei denn, Sie entscheiden, dass er eine Anforderung nicht richtig darstellt.

Am Ende jedes kleinen Schritts führen Sie alle Komponententests aus, die für den jeweiligen Codebereich relevant sind. Der Schritt wird erst dann als vollständig betrachtet, wenn jeder Test erfolgreich abgeschlossen wurde.

Sie checken den Code erst bei Azure DevOps Server ein, wenn Sie die gesamte Aufgabe abgeschlossen haben.

Sie können für diese aus kleinen Schritten bestehende Folge einen groben Plan aufstellen. Sie wissen, dass sich die Details und die genaue Reihenfolge von nachfolgenden Plänen mit fortschreitender Arbeit wahrscheinlich ändern werden. Im Folgenden sehen Sie die erste Liste der für diese bestimmte Aufgabe erforderlichen Schritte:

1. Testmethodenstub erstellen, d. h. nur die Signatur der Methode.
2. Einen typischen Fall erfüllen.
3. Einen großen Bereich testen. Sicherstellen, dass der Code ordnungsgemäß auf einen großen Wertebereich reagiert.
4. Bei negativem Ergebnis Ausnahme ausgeben. Falsche Parameter ordnungsgemäß behandeln.
5. Code Coverage. Stellen Sie sicher, dass mindestens 80% des Codes durch die Komponententests ausgeführt werden.

Einige Entwickler fügen einen solchen Plan als Kommentare in ihren Code ein. Andere merken sich den Plan lediglich. Es kann hilfreich sein, die Liste der Schritte in das Feld Beschreibung des Arbeitselements zu schreiben. Wenn Sie sich dann vorübergehend einer dringenderen Aufgabe widmen müssen, wissen Sie später genau, wo die Liste zu finden ist.

Den ersten Komponententest erstellen

Erstellen Sie zunächst einen Komponententest. Beginnen Sie mit dem Komponententest, weil Sie ein Codebeispiel schreiben möchten, das Ihre neue Klasse verwendet.

Da dies der erste Komponententest für die zu testende Klassenbibliothek ist, erstellen Sie er ein neues Komponententestprojekt.

1. Wählen Sie Datei>Neues Projekt.
2. Wählen Sie im Dialogfeld Neues Projekt erstellen den Pfeil neben Alle Sprachen und dann C# aus, wählen Sie den Pfeil neben Alle Projekttypen, dann Test und dann MSTest-Testprojekt aus.
3. Wählen Sie Weiter und anschließend Erstellen aus.

Ersetzen Sie im Code-Editor den Inhalt von UnitTest1.cs durch den folgenden Code. In diesem Stadium möchten Sie lediglich veranschaulichen, wie eine Ihrer 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);
        }
    }
}

Sie schreiben das Beispiel in einer Testmethode, da das Beispiel bis zum Schreiben des Codes funktionieren soll.

Erstellen eines Komponententestprojekts und von Methoden

Normalerweise erstellen Sie für jedes zu testende Projekt ein neues Testprojekt. Wenn aber bereits ein Testprojekt vorhanden ist, können Sie diesem neue Testmethoden und Klassen hinzufügen.

In diesem Tutorial wird das Visual Studio-Komponententestframework verwendet. Sie können aber auch Frameworks anderer Anbieter verwenden. Test-Explorer funktioniert ebenso mit anderen Frameworks, sofern Sie den entsprechenden Adapter installieren.

1. Erstellen Sie ein Testprojekt, indem Sie die vorherigen Schritte ausführen. Sie können Sprachen wie z. B. C#, F# und Visual Basic auswählen.

2. Fügen Sie die Tests zur bereitgestellten Testklasse hinzu. Jeder Komponententest ist eine Methode.

   • Jedem Komponententest muss das Attribut TestMethod vorangestellt werden. Die Komponententestmethode darf keine Parameter aufweisen. Sie können für eine Komponententestmethode einen beliebigen Namen verwenden:

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

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

   • Für jede Testmethode muss eine Methode der Klasse Assert aufgerufen und angeben werden, ob sie erfolgreich oder fehlerhaft war. In der Regel überprüfen Sie, ob die erwarteten und tatsächlichen Ergebnisse einer Operation übereinstimmen:

     Assert.AreEqual(expectedResult, actualResult);
     

     Assert.AreEqual(expectedResult, actualResult)
     

   • In Ihren Testmethoden können andere gewöhnliche Methoden aufgerufen werden, die nicht das Attribut TestMethod aufweisen.

   • Sie können die Tests in mehreren Klassen organisieren. Jeder Klasse muss das Attribut TestClass vorangestellt werden.

     [TestClass]
     public class UnitTest1
     { ... }
     

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

Informationen zum Schreiben von Komponententests in C++ finden Sie unter Schreiben von Komponententests für C/C++ mit dem Microsoft-Unittest-Framework für C++.

Einen Stub für den neuen Code erstellen

Als Nächstes erstellen Sie ein neues Klassenbibliotheksprojekt für Ihren neuen Code. Es gibt jetzt ein Projekt für den Code in der Entwicklung und ein Projekt für die Komponententests. Es wird ein Projektverweis vom Testprojekt zum Code in der Entwicklung hinzugefügt.

In dem neuen Projekt fügen Sie die neue Klasse und eine Mindestversion der Methode hinzu, mit der sich der Test zumindest erfolgreich erstellen lässt. Am schnellsten lässt sich dies durch Generieren eines Klassen- und Methodenstubs über den Aufruf im Test erreichen.

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

Generieren von Klassen und Methoden aus Tests

Erstellen Sie zunächst das Projekt, dem Sie die neue Klasse hinzufügen möchten, sofern es noch nicht vorhanden ist.

Generieren einer Klasse

1. Platzieren Sie den Cursor in einem Beispiel der zu generierenden Klasse, zum Beispiel LocalMath, und wählen Sie Schnellaktionen und Refactorings aus.
2. Wählen Sie im Kontextmenü die Option Neuen Typ generieren aus.
3. Legen Sie im Dialogfeld Typ generieren unter Projekt das Klassenbibliotheksprojekt fest. Im vorliegenden Beispiel handelt ist das Fabrikam.Math.

Generieren einer Methode

1. Platzieren Sie den Cursor auf einen Aufruf der Methode, z. B. SquareRoot, und wählen Sie Schnellaktionen und Refactorings aus.
2. Klicken Sie im Kontextmenü auf Methode „SquareRoot“ generieren.

Den ersten Test ausführen

Erstellen Sie den Test und führen Sie ihn aus. Im Testergebnis wird ein roter Fehlerindikator angezeigt. Der Test wird in der Liste Tests mit Fehlern angezeigt.

Nehmen Sie eine einfache Änderung am Code vor:

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

Führen Sie den Test erneut aus. Daraufhin wird er bestanden.

Ausführen von Tests

So führen Sie Tests aus:

• Wählen Sie Test>Alle Tests ausführen aus.
• Oder wählen Sie, wenn der Test-Explorer geöffnet ist, die Option Ausführen oder die Option Alle Tests in der Ansicht ausführen aus.

Wenn ein Test unter Tests mit Fehlern angezeigt wird, öffnen Sie den Test, indem Sie z. B. auf den Namen doppelklicken. Der Punkt, an dem der Test fehlgeschlagen ist, wird im Code-Editor angezeigt.

• Wenn Sie eine vollständige Liste der Tests anzeigen möchten, klicken Sie auf Alle anzeigen.

• Wenn Sie die Details eines Testergebnisses anzeigen möchten, wählen Sie den Test im Test-Explorer aus.

• Um zum Testcode zu navigieren, doppelklicken Sie im Test-Explorer auf den Test, oder wählen Sie im Kontextmenü die Option Test öffnen aus.

• Um einen Test zu debuggen, öffnen Sie das Kontextmenü für einen oder mehrere Tests, und wählen Sie dann die Option Debuggen aus.

• Wenn Sie beim Erstellen der Projektmappe Tests im Hintergrund ausführen möchten, wählen Sie den Pfeil neben dem Symbol Einstellungen und dann Tests nach dem Build ausführen aus. Zuvor fehlerhafte Tests werden zuerst ausgeführt.

Vereinbarung über die Schnittstelle

Sie können mit Kollegen zusammenarbeiten, die Ihre Komponente verwenden, indem Sie Ihren Bildschirm freigeben. Ein Kollege könnte anmerken, dass viele Funktionen den vorherigen Test bestehen würden. Erläutern Sie, dass dieser Test nur dazu dient, sicherzustellen, dass der Name und die Parameter der Funktion richtig sind. Jetzt können Sie einen Test schreiben, der die Hauptanforderung dieser Funktion erfasst.

Sie arbeiten mit Kollegen zusammen, um den folgenden Test zu schreiben:

[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 verwenden Sie die Test-First-Entwicklung, bei der Sie zunächst den Komponententest einer Funktion und anschließend den Code schreiben, mit dem Sie den Test bestehen. In anderen Fällen ist diese Vorgehensweise nicht realistisch, sodass Sie die Tests schreiben, nachdem Sie den Code geschrieben haben. Das Schreiben von Komponententests – sei es vor oder nach dem Code – ist jedoch sehr wichtig, weil dadurch der Code stabil bleibt.

Rot, Grün, Umgestalten...

Gehen Sie nach einem bestimmten Zyklus vor, in dem Sie wiederholt einen Test schreiben und sich vergewissern, dass er fehlerhaft verläuft. Daraufhin schreiben Sie einen Code, mit dem der Test erfolgreich abgeschlossen wird, und erwägen ein Refactoring, d. h. Sie erweitern den Code, ohne die Tests zu ändern.

Red

Führen Sie alle Tests aus, einschließlich des neuen Tests, den Sie erstellt haben. Wenn Sie einen Test geschrieben haben, führen Sie ihn immer aus, um sicherzustellen, dass ein Fehler auftritt. Erst dann schreiben Sie den Code, mit dem der Test erfolgreich abgeschlossen wird. Wenn Sie z. B. vergessen, Assertionen in einigen Tests zu platzieren, die Sie schreiben, können Sie durch das Fehler-Ergebnis sicher sein, dass das Testergebnis, wenn der Test bestanden wurde, korrekt angibt, dass eine Anforderung erfüllt wurde.

Des Weiteren empfiehlt es sich, die Option Tests nach dem Buildvorgang ausführen festzulegen. Damit werden die Tests bei jeder Erstellung der Projektmappe im Hintergrund ausgeführt, und Sie erhalten einen fortlaufenden Bericht über den Teststatus des Codes. Möglicherweise haben Sie Bedenken, dass diese Vorgehensweise dazu führen könnte, dass Visual Studio langsam reagiert, aber dies geschieht selten.

Grün

Unternehmen Sie einen ersten Versuch, den Code für Ihre Methode zu schreiben:

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

Führen Sie die Tests erneut aus. Alle Tests werden bestanden.

Refactoring

Da der Code nun seine Hauptfunktion erfüllt, suchen Sie nach Möglichkeiten, ihn zu optimieren bzw. ihn in Zukunft leichter ändern zu können. Sie können die Anzahl der Berechnungen reduzieren, 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;
    }

Vergewissern Sie sich, dass die Tests weiterhin bestanden werden.

Tipps

• Jede Änderung, die Sie bei der Codeentwicklung vornehmen, sollte entweder ein Refactoring oder eine Erweiterung sein:

  • Refactoring bedeutet, dass Sie die Tests nicht ändern, da Sie keine neuen Funktionen hinzufügen.
  • Eine Erweiterung bedeutet, dass Tests hinzugefügt und Codeänderungen vorgenommen werden, die für das Bestehen von vorhandenen und neuen Tests erforderlich sind.

• Wenn Sie vorhandenen Code an geänderte Anforderungen anpassen, löschen Sie gleichzeitig alte Tests, die den aktuellen Anforderungen nicht mehr entsprechen.

• Vermeiden Sie es, Tests zu ändern, die bereits bestanden wurden. Fügen Sie stattdessen lieber neue Tests hinzu. Schreiben Sie nur Tests, die einer echten Anforderung entsprechen.

• Führen Sie die Tests nach jeder Änderung durch.

...und noch einmal

Setzen Sie die Reihe von Erweiterungs- und Umgestaltungsschritten fort. Ihre Liste dient Ihnen dabei als grober Leitfaden. Es folgt nicht auf jede Erweiterung ein Refactoringschritt, und manchmal werden auch mehrere Refactoringschritte hintereinander ausgeführt. Allerdings folgen auf jede Codeänderung Komponententests.

Manchmal fügen Sie einen Test hinzu, der keine Codeänderung erfordert. Dieser Test macht Sie noch sicherer, dass Ihr Code ordnungsgemäß funktioniert. Sie möchten beispielsweise überprüfen, ob die Funktion einen breites Eingabespektrum abdeckt. Hierzu schreiben Sie weitere Tests, z. B.:

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

Dieser Test ist bei seiner ersten Ausführung erfolgreich.

Um sich zu vergewissern, dass dies kein falsch-positives Ergebnis ist, können Sie vorübergehend einen kleinen Fehler in den Test einbauen, der den Test fehlschlägen lässt. Nachdem Sie den Fehler gesehen haben, können Sie ihn erneut beheben.

Tipp

Es empfiehlt sich, einen Test immer zunächst fehlschlagen zu lassen, bevor er erfolgreich abgeschlossen wird.

Ausnahmen

Wenden Sie sich nun dem Schreiben von Tests für Ausnahmeeingaben zu:

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

Bei diesem Test wird der Code in eine Schleife gesetzt. Sie müssen auf die Schaltfläche Abbrechen im Test-Explorer klicken. Dadurch wird der Code innerhalb von 10 Sekunden angehalten.

Sie möchten überprüfen, ob eine Endlosschleife nicht auch auf dem Buildserver auftreten kann. Der Server erzwingt zwar bei einer vollständigen Ausführung ein Timeout, dieses ist aber sehr lang und würde zu einer beträchtlichen Verzögerung führen. Daher können Sie diesem Test ein explizites Timeout hinzufügen:

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

Das explizite Timeout bewirkt, dass der Test fehlschlägt.

Aktualisieren Sie den Code, um diesen Ausnahmefall zu behandeln:

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

Regression

Der neue Test wird bestanden; allerdings tritt eine Regression auf. Der eben noch erfolgreiche Test schlägt nun fehl:

Suchen Sie den Fehler und beheben Sie ihn:

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

Anschließend sind alle Tests erfolgreich:

Tipp

Vergewissern Sie sich nach jeder Codeänderung, dass alle Tests bestanden werden.

Codeabdeckung

Rufen Sie in Intervallen während Ihrer Arbeit und schließlich vor dem Einchecken des Codes einen Code Coverage-Bericht ab. In diesem Bericht wird angegeben, welcher Anteil des Codes durch Ihre die Tests untersucht wurde.

Ihr Team strebt einen Anteil von mindestens 80% an. Für generierten Code wird diese Anforderung weniger streng gehandhabt, da es schwierig sein kann, für diesen Codetyp eine hohe Abdeckung zu erreichen.

Eine gute Codeabdeckung garantiert weder die vollständige Funktionalität einer getesteten Komponente noch die Funktionsfähigkeit des Codes in jedem Bereich von Eingabewerten. Trotzdem gibt es einen engen Zusammenhang zwischen der Abdeckung von Codezeilen und der des verhaltensgesteuerten Bereichs einer Komponente. Daher bestärkt eine gute Codeabdeckung ein Team darin, dass sie auch wirklich den erforderlichen Großteil des Codeverhaltens testen.

Um einen Codeabdeckungsbericht zu erhalten, wählen Sie im Visual Studio-Test-Menü die Option Codeabdeckung für alle Tests analysieren aus. Alle Tests werden erneut ausgeführt.

Wenn Sie die Summe im Bericht einblenden, sehen Sie, dass der von Ihnen entwickelte Code eine vollständige Abdeckung aufweist. Das ist äußerst zufriedenstellend, da der zu testende Code am wichtigsten ist. Die nicht abgedeckten Abschnitte befinden sich nämlich in den Tests selbst.

Durch Betätigen der Umschaltfläche Code Coverage-Färbung anzeigen kann Peter herausfinden, welche Teile des Testcodes nicht untersucht wurden. Code, der nicht in den Tests verwendet wurde, ist orange hervorgehoben. Diese Abschnitt sind jedoch für die Codeabdeckung bedeutungslos, da sie sich im Testcode befinden und nur bei Feststellung eines Fehlers verwendet werden.

Wenn Sie überprüfen möchten, ob ein bestimmter Test in bestimmte Codeverzweigungen hineinreicht, können Sie die Option Code Coverage-Färbung anzeigen aktivieren und anschließend den Test über den Befehl Ausführen im Kontextmenü ausführen.

Wann sind Sie fertig?

Sie fährt fort, den Code in kleinen Schritten zu aktualisieren, bis die folgenden Kriterien erfüllt sind:

• Alle verfügbaren Komponententests wurden bestanden.

  Bei Projekten mit besonders vielen Komponententests können Entwickler möglicherweise nicht abwarten, bis alle Tests ausgeführt wurden. Stattdessen führt das Projekt einen Gated-Check-In aus, bei dem alle automatisierten Tests für jedes eingecheckte Shelveset ausgeführt und anschließend in der Quellstruktur zusammengeführt werden. Das Einchecken wird abgelehnt, wenn die Ausführung fehlschlägt. So kann der Entwickler einen minimalen Satz von Komponententests auf seinem eigenen Computer ausführen und anschließend andere Aufgaben fortsetzen, ohne den Build zu beschädigen. Weitere Informationen finden Sie unter Verwenden eines Gated-Check-In-Buildprozesses zum Überprüfen von Änderungen.

• Die Code Coverage entspricht dem Standard des Teams. Die Projektanforderung liegt in der Regel bei 75%.

• Die Komponententests simulieren alle Aspekte des erforderlichen Verhaltens, einschließlich typischer und Ausnahmeeingaben.

• Der Code ist leicht verständlich und erweiterbar.

Wenn alle genannten Kriterien erfüllt sind, können Sie den Code in die Quellcodeverwaltung einchecken.

Grundlagen der Codeentwicklung mit Komponententests

Wenden Sie bei der Codeentwickelung die folgenden Grundlagen an:

• Komponententests zusammen mit dem Code entwickeln und während der Entwicklung häufig ausführen. Die Komponententests stellen die Spezifikation der Komponente dar.
• Komponententests nur bei geänderten Anforderungen oder falschen Tests ändern. Neue Tests bei der Erweiterung der Codefunktionalität nach und nach hinzufügen.
• Testziel: Mindestens 75% Codeabdeckung. Regelmäßig und vor dem Einchecken des Quellcodes die Code Coverage-Ergebnisse überprüfen.
• Checken Sie die Komponententests zusammen mit dem Code ein, sodass sie von den fortlaufenden oder regulären Serverbuildvorgängen ausgeführt werden.
• Für jede einzelne Funktion ggf. zuerst den Komponententest schreiben. Tun Sie dies, bevor Sie den Code entwickeln, der die Funktion erfüllt.

Die Änderungen einchecken

Bevor Sie Änderungen einchecken, teilen Sie Ihren Bildschirm erneut mit Kollegen, damit diese informell und interaktiv mit Ihnen überprüfen können, was Sie erstellt haben. Die Tests werden weiterhin im Fokus Ihrer Diskussion mit Kollegen stehen, die sich hauptsächlich dafür interessieren, welchen Zweck der Codes hat und nicht, wie er funktioniert. Diese Kollegen sollten sich darüber einig sein, dass das, was Sie geschrieben haben, ihren Anforderungen entspricht.

Überprüfen Sie alle Änderungen, die Sie vorgenommen haben, einschließlich der Tests und des Codes, und ordnen Sie sie den abgeschlossenen Aufgaben zu. Beim Einchecken wird das automatisierte Buildsystem des Teams in die Warteschlange gestellt, damit seine Änderungen anhand des Buildprozesses für den CI-Build des Teams überprüft werden können. Dies trägt zur Fehlerminimierung in der Codebasis des Teams bei. Bei dem Buildprozess werden in einer unveränderten und von den Entwicklungscomputern getrennten Umgebung alle vom Team vorgenommenen Änderungen erstellt und getestet.

Sie werden benachrichtigt, sobald der Build fertig ist. Im Fenster mit den Buildergebnissen sehen Sie, dass der Build erfolgreich erstellt und alle Tests bestanden wurden.

Die Änderungen einchecken

1. Wählen Sie auf der Seite Meine Arbeit in Team Explorer die Option Einchecken aus.

   

2. Vergewissern Sie sich auf der Seite Ausstehende Änderungen, dass Folgendes zutrifft:

   • Alle relevanten Änderungen werden unter Eingeschlossene Änderungen aufgeführt.
   • Alle relevanten Arbeitselemente werden unter Verknüpfte Arbeitselemente aufgeführt.

3. Geben Sie einen Kommentar ein. So vermitteln Sie den Teammitgliedern den Zweck der vorgenommenen Änderungen, wenn sie sich den Versionskontrollverlauf der geänderten Dateien und Ordner ansehen.

4. Wählen Sie Einchecken aus.

   

Fortlaufende Integration des Codes

Weitere Informationen zum Definieren eines Bildprozesses mit fortlaufender Integration finden Sie unter Einrichten eines CI-Builds. Nach der Einrichtung dieses Buildprozesses können Sie sich auf Wunsch über die Ergebnisse der Teambuilds benachrichtigen lassen.

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

Nächste Schritte

Anhalten der Arbeit, Beheben eines Fehlers und Durchführen einer Codeüberprüfung