Dzień z życia programisty ALM: pisanie nowego kodu dla scenariuszy użycia

 

Jesteś nowym użytkownikiem aplikacji Visual Studio Application Lifecycle Management (ALM) i Team Foundation Server (TFS)? Czy zastanawiasz się jak Ty i Twój zespół może uzyskać maksymalną korzyść z najnowszych wersji tych narzędzi podczas tworzenia aplikacji?

Poświęć kilka minut, aby przejść krok po kroku przez dwu rozdziałowy samouczek i podążaj za dniem z życia Piotra i Julii, dwóch programistów w Fabrikam Fiber — fikcyjnej firmy, która dostarcza telewizję kablową i związane z nią usługi. Zobaczysz przykłady jak można użyć Visual Studio i TFS, aby sprawdzić i zaktualizować kod, zawiesić pracę, gdy jest przerwana, wnioskować o dokonanie przeglądu kodu, zewidencjonować zmiany i wykonywać inne zadania.

Do tej pory

Zespół ostatnio zaczął przystosowywanie programu Visual Studio i Team Foundation Server do zarządzania cyklem życia aplikacji (ALM). Ustawiają oni swój serwer i komputery klienckie, utworzone zaległości, planowane iteracje i zakończone inne planowania niezbędne do rozpoczęcia rozwoju ich aplikacji.

Omówienie niniejszego rozdziału

Piotr krótko przegląda zaległości i wybiera zadanie, nad którym będzie dzisiaj pracował. Pisze testy jednostkowe dla kodu, który zamierza rozwijać. Zazwyczaj uruchamia testy kilka razy w ciągu godziny, stopniowo pisząc bardziej szczegółowe testy a następnie tworząc kod, który je spełnia. Często omawia interfejs swojego kodu z kolegami używający metody, którą pisze.

Uwaga

Funkcje moja praca i pokrycie kodu, które zostały omówione w tym temacie są dostępne tylko w Visual Studio Premium i Visual Studio Ultimate.

W tym temacie

• Przegląd zaległości osobistych i przygotowanie zadań do rozpoczęcia pracy

• Tworzenie pierwszego testu jednostkowego

• Tworzenie szkieletu dla nowego kodu

• Uruchamianie pierwszego testu

• Potwierdzanie interfejsu API

• Czerwony, zielony, refaktoryzacja...

• Pokrycie kodu

• Kiedy następuje koniec?

• Ewidencjonowanie zmian

Przegląd zaległości osobistych i przygotowanie zadań do rozpoczęcia pracy

W Team Explorer, Piotr otwiera stronę Moja praca. Zespół zgodził się, że podczas bieżącego sprintu, Piotr będzie pracować nad stanem faktury Szacuj, elementem o najwyższym priorytecie w zaległości produktu. Piotr postanawia rozpocząć Implementowanie funkcji matematycznych, zadania podrzędne elementu zaległości z najwyższym priorytetem. Przeciąga to zadanie z listy Dostępne elementy pracy do listy Elementy & zmiany pracy w toku.

Aby przeglądać zaległości osobiste i przygotować zadania do rozpoczęcia pracy

1. W Team Explorer:

   1. Jeśli nie jesteś podłączony do projektu zespołowego, przy którym chcesz pracować, to połącz się z projektem zespołowym.

   2. Wybierz Strona główna, a następnie wybierz polecenie Moja praca.

2. Na stronie Moja praca, przeciągnij zadanie z listy Dostępne elementy pracy do sekcji Elementy pracy w toku.

   Można również wybrać zadania z listy Dostępne elementy pracy, a następnie wybrać Start.

Projekt planu prac przyrostowych

Piotr zazwyczaj rozwija kod jako ciąg małych kroków. Każdy krok trwa zazwyczaj nie dłużej niż godzinę, a może trwać nawet 10 minut. W każdym kroku pisze nowe testy jednostkowe i zmienia kod, który rozwija tak, aby przeszedł nowe testy, oprócz tych, których już jest autorem. Czasami pisze nowe testy przed zmianą kodu, a czasem zmienia kod przed napisaniem testu. Czasami też refaktoryzuje. Oznacza to, że on po prostu zwiększa kod bez dodawania nowych testów. Nigdy nie zmienia testu, który przechodzi, o ile nie stwierdzi, że ten nie spełnia poprawnie wymagań.

Na koniec każdego małego kroku prowadzi wszystkie testy jednostkowe, które odnoszą się do tego obszaru kodu. Traktuje krok jako zakończony dopiero, gdy każdy test zakończył się pomyślnie.

Jednak on nie będzie sprawdzać kodu w programie Team Foundation Server, aż zakończy całe zadanie.

Piotr spisuje surowy plan dla tej sekwencji małych kroków. Wie, że dokładne szczegóły i kolejność prawdopodobnie zmieni później podczas pracy. Oto jego wstępna lista kroków dla tego konkretnego zadania:

1. Utwórz skrótową metodę testową — tylko sygnatura metody.

2. Wykonaj jeden konkretny przypadek.

3. Przetestuj szeroki zakres. Upewnij się, że kod odpowiada poprawnie na duży zakres wartości.

4. Wyjątek dla niepowodzeń. Łagodnie poradź sobie z niepoprawnymi parametrami.

5. Pokrycie kodu. Upewnij się, że co najmniej w 80% kod jest wykonywany przez testy jednostkowe.

Część z kolegów pisze ten rodzaj planu w komentarzach w kodzie testu. Inni po prostu zapamiętują swój plan. Piotr uznaje za przydatne zapisanie listy kroków w polu opis dla elementu zadania pracy. Jeśli musiał tymczasowo przełączyć się na bardziej pilne zadania, wie, gdzie można znaleźć listę, gdy jest on w stanie powrócić do poprzedniego.

Tworzenie pierwszego testu jednostkowego

Piotr rozpoczyna się od utworzenia testów jednostkowych. Zaczyna od testu jednostkowego, ponieważ chce napisać przykładowy kod, który używa jego nowa klasa.

To pierwszy test jednostkowy dla biblioteki klas, która jest testowana, więc tworzy nowy projekt testu jednostkowego. Otwiera on okno dialogowe Nowy projekt i wybiera program Visual C#, Test, a następnie Projekt testu jednostkowego.

Projekt testu jednostkowego zawiera plik języka C#, w którym może on pisać swój przykład. Na tym etapie po prostu chce zilustrować, jak jedna z jego nowych metod będzie wywoływana:

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

Pisze przykład w metodzie testowej, ponieważ od czasu, gdy jest autorem kodu, potrzebuje przykładu do pracy.

Aby utworzyć projekt testu jednostkowego i metody

Zazwyczaj należy utworzyć nowy projekt testu dla każdego projektu, który jest testowany. Jeśli projekt testowy już istnieje, można po prostu dodać nowe metody testowe i klasy.

Ta procedura używa frameworka testów jednostkowych programu Visual Studio, ale umożliwia także użycie frameworków od innych dostawców. Eksplorator testów działa równie dobrze z innymi frameworkami, dostarczonymi przez instalację odpowiedniego adaptera.

• Utwórz projekt testowy, jeśli jeszcze nie istnieje.

  • W oknie dialogowym Nowy projekt wybierz język, taki jak Visual Basic, Visual C++ lub Visual C#. Wybierz Test a następnie Projekt testu jednostkowego.

• Dodaj własne testy do dostarczonej klasy testowej. Każdy test jednostkowy jest jedną metodą.

  Każdy test jednostkowy musi być poprzedzony atrybutem TestMethod a metoda testu jednostkowego nie powinna mieć żadnych parametrów. Można użyć dowolną nazwę dla metody testu jednostkowego:

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

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

• Każda metoda testowa powinna wywoływać metodę klasy Assert, aby wskazać, czy przeszła lub nie powiodła się. Zazwyczaj można sprawdzić, czy oczekiwane i rzeczywiste wyniki operacji są równe:

  Assert.AreEqual(expectedResult, actualResult);
  

  Assert.AreEqual(expectedResult, actualResult)
  

• Twoje metody testowe mogą wywołać inne zwykłe metody, które nie mają atrybutu TestMethod.

• Testy można organizować w więcej niż jednej klasie. Każda klasa musi być poprzedzona przez atrybut TestClass.

  [TestClass]
  public class UnitTest1
  { ... }
  

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

Aby uzyskać więcej informacji dotyczących sposobu pisania testów jednostkowych w C++, zobacz Framework testów jednostkowych firmy Microsoft dla języka C++ pozwala pisać testy jednostkowe dla projektów języka C++..

Tworzenie szkieletu dla nowego kodu

Następnie Piotr tworzy projekt biblioteki klas dla jego nowy kodu. Obecnie istnieje projekt dla kodu w opracowaniu i projektu do testów jednostkowych. On dodaje odwołanie projektu z projektu testowego do kodu w opracowaniu.

W nowym projekcie dodaje nową klasę i minimalną wersję metody, która pozwoli przynajmniej zbudować pomyślnie test. Najszybszym sposobem na to jest wygenerowanie klasy i metody skrótowej z wywołania w teście.

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

Do generowania klasy i metody z testów

Najpierw należy utworzyć projekt, w którym chcesz dodać nową klasę, chyba że już istnieje.

Aby wygenerować klasy

1. Umieść kursor na przykładzie klasy, która ma zostać wygenerowana, na przykład, LocalMath. W menu skrótów wybierz polecenie Generuj kod, Nowy typ.

2. W oknie dialogowym Nowy typ, ustaw Projekt do projektu biblioteki klas. W tym przykładzie jest to Fabrikam.Math.

Aby wygenerować metody

• Umieść kursor na wywołaniu metody, na przykład, SquareRoot. W menu skrótów wybierz polecenie Generuj kod, Skrótowych metody.

Uruchom test pierwszy

Piotr tworzy i uruchamiania test naciskając klawisze CTRL + R, T. Wynik testu pokazuje czerwony wskaźnik niepowodzenia i test pojawia się w obszarze listy Testy zakończone niepowodzeniem.

Tworzy on, że proste zmiany do kodu:

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

Ponownie uruchamia testy i przechodzi:

Aby uruchomić testy jednostkowe

• W menu Test, wybierz polecenie Uruchom, Wszystkie testy.

  -lub-

• Jeśli eksplorator testów jest otwarty, wybierz polecenie Uruchom wszystkie.

  - lub -

• Umieść kursor w pliku kodu testowego i naciśnij klawisz CTRL + R, T.

• Jeśli test pojawi się pod Testy zakończone niepowodzeniem.

  Otwórz testy, na przykład przez dwukrotne kliknięcie nazwy.

  Wyświetlony jest punkt, w którym test się nie powiódł.

Aby zapoznać się z listą testów, wybierz Pokaż wszystkie. Aby powrócić do podsumowania, wybierz widok Strona główna.

Aby zobaczyć szczegółowe wyniki testu wybierz test w eksploratorze testów.

Aby przejść do kodu testu, kliknij dwukrotnie test w Eksploratorze testów lub wybierz Otwórz test w menu skrótów.

Aby debugować test, otwórz menu skrótów jednego lub więcej testów, a następnie wybierz Debuguj wybrane testy.

Aby uruchomić testy w tle, przy każdej kompilacji rozwiązania, przełącz Uruchom testy po kompilacji. Testy, które nie zakończyły się niepowodzeniem wcześniej są uruchamiane jako pierwsze.

Potwierdź interfejs

Piotr dzwoni do swojej koleżanki Julii przez Lync i udostępnia swój ekran. Będzie ona używać jego składników. Pokazuje on swój początkowy przykład.

Julia uważa, że w przykładzie jest OK, ale komentuje "wiele funkcji przejdzie test."

Piotr odpowiada, "pierwszy test jest tylko, aby upewnić się, że nazwa i parametry funkcji są poprawne. Teraz możemy napisać test, który przechwytuje główne wymaganie tej funkcji."

Razem zapisują następujący 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);
  }

Porada

Dla tej funkcji Piotr używa testu rozwoju pierwszego, w którym po raz pierwszy pisze test jednostki dla funkcji i następnie pisze kod, który spełnia kryteria.W innych przypadkach stwierdza on, że taka praktyka nie jest realna, zamiast tego pisze testy po napisaniu kodu.Ale uważa to bardzo ważne, aby pisać testy jednostkowe — przed lub po kodzie — ponieważ kod jest wtedy stabilny.

Czerwony, zielony, refaktoryzacja...

Piotr postępuje według cyklu, w którym wielokrotnie pisze test i potwierdza, że nie powiedzie się, pisze kod, aby wykonać próbę powodzenia, a następnie używa refaktoryzacji — to znaczy, poprawę kodu bez zmiany testów.

Czerwony

Piotr naciska klawisze CTRL + R, T, aby uruchomić nowy test, który utworzył z Julią. Po napisaniu dowolnego testu on zawsze uruchamia go, aby upewnić się, że nie powiedzie się bez napisania kodu, który sprawi, jego powodzenie. Jest to praktyka, której nauczył się, gdy zapomniał umieścić asercje w niektórych testach, które napisał. Widząc wynik Niepowodzenie daje mu to pewność, że gdy sprawi, że test przejdzie to wynik tego testu będzie poprawnie wskazywał, że wymaganie zostało spełnione.

Inną przydatną praktyką jest ustawienie Uruchom testy po kompilacji. Ta opcja uruchamia testy w tle każdorazowo podczas budowania rozwiązania, tak, że ciągle raportuje stan testu kodu. Piotr początkowo podejrzewał, że mógł uczynić, że Visual Studio wolno reaguje, ale stwierdził, że to się rzadko zdarza.

Zielony

Piotr pisze jego pierwszą próbę kodu metody, którą rozwija:

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

Piotr ponownie uruchamia testy i wszystkie testy kończą się pomyślnie:

Refaktoryzacja

Teraz, ponieważ kod wykonuje swoją główną funkcję, Piotr analizuje go do znalezienia sposobów zwiększenia wydajności lub aby ułatwić zmiany w przyszłości. Uświadamia sobie, że może zmniejszyć liczbę obliczeń wykonywanych w pętli:

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

Sprawdza on, czy testy jeszcze przechodzą:

Porada

Wszystkie zmiany wprowadzone podczas opracowywania kodu powinny być refaktoryzacją lub rozszerzeniem:

• Refaktoryzacja oznacza, że nie należy zmieniać testów ponieważ nie dodajesz nowej funkcjonalności.

• Rozszerzenie oznacza dodanie testów i dokonywanie zmian kodu, które są niezbędne do przejścia testów zarówno istniejących, jak i nowych.

Jeśli aktualizujesz istniejący kod do wymogów, które uległy zmianie, spowoduje to również usunięcie starych testów, które nie reprezentują bieżących wymagań.

Należy unikać zmieniania testów, które już się powiodły.Zamiast tego, dodaj nowe testy.Należy pisać tylko testy, które reprezentują rzeczywiste wymagania.

Uruchom testy po każdej zmianie.

... i powtórz

Piotr kontynuuje serię kroków rozszerzenia i refaktoryzacji, jako ogólna wskazówka przy użyciu jego listy małych kroków. Nie zawsze wykonuje refaktoryzacji kroków po każdym rozszerzeniu, czasami występuje więcej niż jeden krok refaktoryzacji w odstępie czasu. Ale zawsze uruchamia testy jednostkowe po każdej zmianie kodu.

Czasami dodaje test, który nie wymaga żadnych zmian w kodzie, ale który zwiększa jego pewność, że jego kod działa poprawnie. Na przykład chce się upewnić, że działa on w szerokim zakresie danych wejściowych. Pisze więcej testów, takich jak:

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

Ten test zakończył się pomyślnie przy pierwszym uruchomieniu:

Tylko po to, aby upewnić się, że wynik ten nie jest błędem, on tymczasowo wprowadza mały błąd w jego test, aby się nie powiódł. Po obejrzeniu awarii, on rozwiązuje go ponownie.

Porada

Zawsze wykonaj próbę niepowodzenia testu przed sprawieniem, że się on powiedzie.

Wyjątki

Piotr teraz przechodzi do pisania testów dla błędnych danych wejściowych:

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

Ten test umieszcza kod w pętli. Musi używać przycisku Anuluj w programie eksplorator testów. Kod ten kończy się w ciągu 10 sekund.

Piotr chce mieć pewność, że pętla nieskończona nie może się zdarzyć na serwerze kompilacji. Chociaż serwer nakłada limit czasu na zakończenie uruchomienia, czas oczekiwania jest bardzo długi i mogłoby spowodować znaczne opóźnienia. W związku z tym jawne dodaje limit czasu do tego testu:

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

Jawny limit czasu sprawia, że test się nie może powieść.

Piotr następnie aktualizuje kod, aby poradzić sobie z tym wyjątkowym przypadkiem:

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

Regresja

Nowy test przechodzi, ale istnieje regresja. Test, który jest używany do przekazywania ulegnie awarii:

Piotr wyszukuje i naprawia błąd:

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

Po poprawkach, wszystkie testy zostały zakończone pomyślnie:

Porada

Upewnij się, że każdy test przechodzi po każdej zmianie wprowadzonej do kodu.

Pokrycie kodu

W odstępach czasu podczas prac i wreszcie przed sprawdzeniem kodu, Piotr uzyskuje raport pokrycia kodu. To wskazuje, jaka część kodu jest sprawdzona przez jego testy.

Celem zespołu Piotra jest pokrycie co najmniej 80%. Oni wyłączają to wymaganie dla wygenerowanego kodu, ponieważ może być trudne osiągnięcie wysokiego pokrycia dla tego typu kodu.

Dobre pokrycie nie jest gwarancją, że wszystkie funkcje składnika zostały przetestowane i nie gwarantuje, że kod będzie działać w przypadku każdego zakresu wartości wejściowych. Niemniej jednak jest dość bliski związek między zapotrzebowaniem wierszy kodu i pokrycia behawioralnego obszaru składnika. W związku z tym dobre pokrycie wzmacnia zaufanie zespołu, że testuje on zachowania, które powinien.

Aby uzyskać raport pokrycia kodu w menu Testy, wybierz polecenie Uruchom, Analizuj pokrycie kodu we wszystkich testach. Następnie ponownie uruchom wszystkie testy.

Piotr otrzymał całkowite pokrycie 86%. Rozszerza on sumy w raporcie, z których wynika, że kod, który on rozwija ma pokrycie 100%. Jest to bardzo zadowalające, ponieważ dla kodu testowanego wynik ten jest ważny. Nie odsłonięte sekcje są faktycznie w samych testach. Przełączając przycisk Pokaż kolorowanie pokrycia kodu, Piotr może zobaczyć części kodu testowego, które nie zostały wykonane. Jednak to on decyduje, że sekcje te są nieistotne dla pokrycia, ponieważ są w kodzie testowym i będą używane, tylko jeśli zostanie wykryty błąd.

Aby zweryfikować, że specyficzny test dotrze do określonych gałęzi kodu, można ustawić Pokaż kolorowanie pokrycia kodu, a następnie uruchomić za pomocą pojedynczego testu polecenie Uruchom z menu skrótów.

Kiedy następuje koniec?

Piotr będzie nadal aktualizował kod w małych krokach, dopóki nie jest przekonany, że:

• Dostępne testy jednostkowe zakończą się powodzeniem.

  W projekcie z bardzo dużą liczbą testów jednostkowych może być niepraktyczne dla deweloperów czekać na uruchomienie ich wszystkich. Zamiast tego, projekt używa usługi bramkowego zaewidencjonowania, w której wszystkie testy automatyczne są uruchamiane dla każdego zestawu zaewidencjonowanego odłożonego przed scaleniem w drzewie źródła. Zaewidencjonowanie zostało odrzucone, jeśli uruchomienie nie powiedzie się. Umożliwia deweloperowi uruchomić minimalny zestaw testów jednostkowych na własnym komputerze, a następnie wykonać inną wykonywaną pracę bez narażania się na zepsucie kompilacji. Aby uzyskać więcej informacji, zobacz Użycie procesu kompilacji ewidencjonowania warunkowego do sprawdzenia poprawności zmian.

• Pokrycie kodu spełnia standardy zespołu. 75% jest typowym wymaganiem projektu.

• Jego testy jednostkowe symulują każdy aspekt zachowania, które jest wymagane, włączając zarówno typowe i wyjątkowe wejścia.

• Jego kod jest łatwy do zrozumienia i rozszerzania.

Gdy wszystkie te kryteria są spełnione, Piotr jest gotowy do sprawdzenia jego kod w kontroli źródła.

Zasady rozwoju kodu z testów jednostkowych

Piotr stosuje się następujące zasady podczas tworzenia kodu:

• Opracowanie testów jednostkowych wraz z kodem i uruchamianie ich często w czasie projektowania. Testy jednostkowe reprezentują specyfikacja składnika.

• Nie należy zmieniać testów jednostkowych, chyba że wymagania zostały zmienione lub testy były błędne. Dodaj nowe testy stopniowo rozszerzając funkcjonalność kodu.

• Minimalnym celem jest pokrycie testami 75% kodu. Spójrz na wyniki pokrycia kodu w odstępach czasu, a przed rozpoczęciem sprawdź to w kodzie źródłowym.

• Zaewidencjonuj testy jednostkowe wraz z kodem, tak, że zostaną uruchomione przez ciągłe lub regularne kompilacje serwera.

• W przypadku gdy jest to praktyczne, zacznij od napisania testów dla każdego rodzaju funkcji. Zrób to przed rozwijaniem kodu, który spełniają.

Zaewidencjonuj zmiany

Przed zaewidencjonowaniem swoich zmian, Piotr używa programu Lync by ponownie udostępnić ekran koleżance Julii, więc ona może nieformalnie i interaktywnie przejrzeć z nim co zostało utworzone. Testy w dalszym ciągu będą przedmiotem dyskusji, ponieważ Julia jest przede wszystkim zainteresowana nie co robi kod, ale jak to działa. Julia zgadza się, że co napisał Piotr spełnia jej wymagania.

Piotr sprawdza wszystkie zmiany jakie dokonał, łącznie z testami i kodem i łączy je z zadaniem, które ukończył. Ewidencjonuje kolejki zespołu automatycznego systemu kompilacji zespołowej do sprawdzania poprawności zmian za pomocą procesu tworzenia procesu kompilacji CI Build zespołu. Proces kompilacji pomaga zespołowi zminimalizować ryzyko wystąpienia błędów w ich bazie kodu przez tworzenie i testowanie każdej zmiany które tworzy zespół w czystym środowisku oddzielnych komputerów deweloperskich.

Piotr jest powiadomiony o zakończeniu kompilacji. W oknie wyników kompilacji, widzi on, że udało się zbudować projekt i wszystkie testy zakończyły się powodzeniem.

Aby zaewidencjonować zmiany

1. Na pasku menu wybierz Widok, Team Explorer.

2. W Team Explorerwybierz Strona główna a następnie Moja praca.

3. W Moja praca wybierz Ewidencjonowanie.

4. Przejrzyj zawartość strony Oczekujące zmiany, aby upewnić się, że:

   • Wszystkie istotne zmiany są wymienione w Uwzględnione zmiany

   • Wszystkie istotne elementy robocze są wymienione w Powiązane elementy robocze.

5. Określ Komentarz, aby ułatwić zespołowi zrozumienie celu tych zmian podczas przeglądania historii kontroli wersji zmienionych plików i folderów.

6. Wybierz Zaewidencjonuj.

Aby zintegrować stale kod

Aby uzyskać więcej informacji na temat definiowania procesu budowania ciągłej integracji, zobacz Konfigurowanie kompilacji CI. Po ustawieniu tego procesu kompilacji, można otrzymywać powiadomienia o wynikach kompilacji zespołu.

Aby uzyskać więcej informacji, zobacz Uruchamiaj, monitoruj i zarządzaj kompilacjami.

Następnie (wstrzymanie pracy, naprawa usterek, przeprowadzanie przeglądu kodu)