devops 개발자의 일상: 사용자 스토리에 대한 새 코드 작성

아티클
04/04/2024

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

Visual Studio 2019 | Visual Studio 2022

이 자습서에서는 사용자와 팀이 최신 버전의 TFVC(Team Foundation 버전 제어) 및 Visual Studio를 통해 앱을 빌드할 수 있는 방법을 안내합니다. 이 자습서에서는 Visual Studio 및 TFVC를 사용하여 코드를 검사 업데이트하고, 중단 시 작업을 일시 중단하고, 코드 검토를 요청하고, 변경 내용을 검사, 다른 작업을 수행하는 방법에 대한 예제를 제공합니다.

팀에서 코드를 관리하기 위해 Visual Studio 및 TFVC를 채택하면 서버 및 클라이언트 머신을 설정하고, 백로그를 만들고, 반복을 계획하고, 앱 개발을 시작하는 데 필요한 다른 계획을 완료합니다.

개발자는 백로그를 검토하여 작업할 작업을 선택합니다. 개발하려는 코드에 대한 단위 테스트를 작성합니다. 일반적으로 테스트를 한 시간에 여러 번 실행하여 점진적으로 더 자세한 테스트를 작성한 다음 통과하게 만드는 코드를 작성합니다. 개발자는 종종 작성 중인 메서드를 사용하는 동료와 코드 인터페이스에 대해 논의합니다.

Visual Studio 내 작업 및 코드 검토 도구를 사용하면 개발자가 작업을 관리하고 동료와 공동 작업할 수 있습니다.

참고 항목

Visual Studio 내 작업 및 코드 검토 기능은 다음 버전에서 사용할 수 있습니다.

Visual Studio 2022: Visual Studio Community, Visual Studio Professional 및 Visual Studio Enterprise
Visual Studio 2019: Visual Studio Professional 및 Visual Studio Enterprise

작업 항목 검토 및 작업 시작 준비

팀은 현재 스프린트 중에 제품 백로그에서 최우선 순위 항목인 청구서 상태 평가 작업을 진행하기로 합의했습니다. 우선 순위가 가장 큰 백로그 항목의 자식 작업인 수학 함수 구현으로 시작합니다.

Visual Studio 팀 탐색기의 내 작업 페이지에서 사용 가능한 작업 항목 목록에서 진행 중인 작업 목록으로 이 작업을 끌어옵니다.

백로그를 검토하고 작업을 시작할 작업을 준비하려면

내 작업 페이지의 스크린샷.

팀 탐색기에서 작업하려는 프로젝트에 아직 연결되지 않은 경우 프로젝트에 연결합니다.
홈페이지에서 내 작업을 선택합니다.
내 작업 페이지의 사용 가능한 작업 항목 목록에서 진행 중인 작업 시간 섹션으로 작업을 끕니다.

사용 가능한 작업 항목 목록에서 작업을 선택한 다음 시작을 선택할 수도 있습니다.

증분 작업 계획 초안

일련의 작은 단계로 코드를 개발합니다. 각 단계는 일반적으로 1시간 이상 걸리지 않으며 10분 정도 걸릴 수 있습니다. 각 단계에서는 새 단위 테스트를 작성하고, 이미 작성한 테스트 외에도 새 테스트를 통과하도록 개발 중인 코드를 변경합니다. 코드를 변경하기 전에 새 테스트를 작성하고 테스트를 작성하기 전에 코드를 변경하는 경우도 있습니다. 경우에 따라 리팩터링합니다. 즉, 새 테스트를 추가하지 않고 코드를 개선할 뿐입니다. 요구 사항을 올바르게 나타내지 않는다고 결정하지 않는 한 통과한 테스트를 변경하지 않습니다.

모든 작은 단계가 끝나면 코드의 이 영역과 관련된 모든 단위 테스트를 실행합니다. 모든 테스트가 통과될 때까지 단계가 완료된 것으로 간주하지 않습니다.

전체 작업을 완료할 때까지 코드에서 Azure DevOps Server에 검사 않습니다.

이 작은 단계 시퀀스에 대한 대략적인 계획을 작성할 수 있습니다. 나중에 작업할 때 정확한 세부 정보 및 순서가 변경될 수 있다는 것을 알고 있습니다. 이 특정 작업에 대한 초기 단계 목록은 다음과 같습니다.

메서드의 서명인 테스트 메서드 스텁을 만듭니다.
하나의 특정 일반적인 사례를 충족합니다.
광범위한 범위를 테스트합니다. 코드가 다양한 값에 올바르게 응답하는지 확인합니다.
음수에 대한 예외입니다. 잘못된 매개 변수를 정상적으로 처리합니다.
코드 검사. 단위 테스트에서 코드의 80% 이상을 실행해야 합니다.

일부 개발자는 테스트 코드의 주석에 이러한 종류의 계획을 작성합니다. 다른 사람들은 단지 자신의 계획을 기억합니다. 작업 작업 항목의 설명 필드에 단계 목록을 작성하는 것이 유용할 수 있습니다. 일시적으로 더 긴급한 작업으로 전환해야 하는 경우 목록으로 돌아갈 수 있을 때 목록을 찾을 수 있는 위치를 알 수 있습니다.

첫 번째 단위 테스트 만들기

단위 테스트를 만들어 시작합니다. 새 클래스를 사용하는 코드의 예제를 작성하려고 하므로 단위 테스트로 시작합니다.

테스트 중인 클래스 라이브러리에 대한 첫 번째 단위 테스트이므로 새 단위 테스트 프로젝트를 만듭니다.

파일>새 프로젝트를 선택합니다.
새 프로젝트 만들기 대화 상자에서 모든 언어 옆에 있는 화살표를 선택하고 C#을 선택하고 모든 프로젝트 형식 옆에 있는 화살표를 선택한 다음 테스트를 선택한 다음 MSTest 테스트 프로젝트를 선택합니다.
다음을 선택하고 만들기를 선택합니다.

새 프로젝트 만들기 대화 상자에서 선택한 단위 테스트의 스크린샷

코드 편집기에서 UnitTest1.cs 내용을 다음 코드로 바꿉니다. 이 단계에서는 새 메서드 중 하나가 호출되는 방법을 보여 주려고 합니다.

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

코드를 작성할 때까지 예제가 작동하도록 하므로 테스트 메서드에서 예제를 작성합니다.

단위 테스트 프로젝트 및 메서드를 만들려면

일반적으로 테스트 중인 각 프로젝트에 대한 새 테스트 프로젝트를 만듭니다. 테스트 프로젝트가 이미 있는 경우 새 테스트 메서드 및 클래스를 추가할 수 있습니다.

이 자습서에서는 Visual Studio 단위 테스트 프레임워크를 사용하지만 다른 공급자의 프레임워크를 사용할 수도 있습니다. 테스트 탐색기는 적절한 어댑터를 설치하는 경우 다른 프레임워크와 동일하게 잘 작동합니다.

이전 단계를 사용하여 테스트 프로젝트를 만듭니다. C#, F# 및 Visual Basic과 같은 언어를 선택할 수 있습니다.
제공된 테스트 클래스에 테스트를 추가합니다. 각 단위 테스트는 하나의 메서드입니다.
- 각 단위 테스트는 특성 앞에 TestMethod 접두사를 지정해야 하며 단위 테스트 메서드에는 매개 변수가 없어야 합니다. 단위 테스트 메서드에 원하는 이름을 사용할 수 있습니다.
```
[TestMethod]
public void SignatureTest()
{...}
```
```
<TestMethod()>
Public Sub SignatureTest()
...
End Sub
```
- 각 테스트 메서드는 클래스의 메서드를 Assert 호출하여 통과 여부를 나타내야 합니다. 일반적으로 작업의 예상 결과와 실제 결과가 같은지 확인합니다.
```
Assert.AreEqual(expectedResult, actualResult);
```
```
Assert.AreEqual(expectedResult, actualResult)
```
- 테스트 메서드는 특성이 없는 다른 일반 메서드를 호출할 TestMethod 수 있습니다.
- 테스트를 둘 이상의 클래스로 구성할 수 있습니다. 각 클래스는 특성 앞에 접두 TestClass 사를 지정해야 합니다.
```
[TestClass]
public class UnitTest1
{ ... }
```
```
<TestClass()>
Public Class UnitTest1
...
End Class
```

C++에서 단위 테스트를 작성하는 방법에 대한 자세한 내용은 C++ 용 Microsoft 단위 테스트 프레임워크를 사용하여 C/C++에 대한 단위 테스트 작성을 참조하세요.

새 코드에 대한 스텁 만들기

다음으로, 새 코드에 대한 클래스 라이브러리 프로젝트를 만듭니다. 이제 개발 중인 코드에 대한 프로젝트와 단위 테스트용 프로젝트가 있습니다. 개발 중인 코드에 테스트 프로젝트의 프로젝트 참조를 추가합니다.

$테스트 및 클래스 프로젝트가 있는 솔루션 탐색기 스크린샷$

새 프로젝트에서는 적어도 테스트가 성공적으로 빌드되도록 허용하는 메서드의 최소 버전과 새 클래스를 추가합니다. 이 작업을 수행하는 가장 빠른 방법은 테스트의 호출에서 클래스 및 메서드 스텁을 생성하는 것입니다.

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

테스트에서 클래스 및 메서드를 생성하려면

먼저 새 클래스가 없는 한 새 클래스를 추가할 프로젝트를 만듭니다.

클래스를 생성하려면

예를 들어 LocalMath생성하려는 클래스의 예제에 커서를 놓고 빠른 작업 및 리팩터링을 선택합니다.
바로 가기 메뉴에서 새 형식 생성을 선택합니다.
형식 생성 대화 상자에서 Project를 클래스 라이브러리 프로젝트로 설정합니다. 이 예제에서는 Fabrikam.Math입니다.

메서드를 생성하려면

예를 들어 SquareRoot메서드 호출에 커서를 놓고 빠른 작업 및 리팩터링을 선택합니다.
바로 가기 메뉴에서 생성 메서드 'SquareRoot'를 선택합니다.

첫 번째 테스트 실행

테스트를 빌드하고 실행합니다. 테스트 결과에 빨간색 실패 표시기가 표시되고 테스트가 실패한 테스트 목록 아래에 표시됩니다.

실패한 테스트 하나를 보여 주는 테스트 탐색기의 스크린샷

코드를 간단하게 변경합니다.

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

테스트를 다시 실행하고 통과합니다.

통과된 테스트가 하나 있는 단위 테스트 탐색기의 스크린샷.

단위 테스트를 실행하려면

단위 테스트를 실행하려면 다음을 수행합니다.

모든 테스트 실행 테스트>선택
또는 테스트 탐색기가 열려 있는 경우 보기에서 모든 테스트 실행 또는 실행을 선택합니다.

모두 실행 단추를 보여 주는 테스트 탐색기의 스크린샷

실패한 테스트 아래에 테스트가 나타나면 예를 들어 이름을 두 번 클릭하여 테스트를 엽니다. 테스트가 실패한 지점이 코드 편집기에서 표시됩니다.

전체 테스트 목록을 보려면 모두 표시를 선택합니다.
테스트 결과의 세부 정보를 보려면 테스트 탐색기에서 테스트를 선택합니다.
테스트 코드로 이동하려면 테스트 탐색기에서 테스트를 두 번 클릭하거나 바로 가기 메뉴에서 테스트 열기를 선택합니다.
테스트를 디버그하려면 하나 이상의 테스트에 대한 바로 가기 메뉴를 열고 디버그를 선택합니다.
솔루션을 빌드할 때마다 백그라운드에서 테스트를 실행하려면 설정 아이콘 옆에 있는 화살표를 선택한 다음 빌드 후 테스트 실행을 선택합니다. 이전에 실패한 테스트가 먼저 실행됩니다.

인터페이스에 동의

화면을 공유하여 구성 요소를 사용할 동료와 공동 작업할 수 있습니다. 동료는 많은 함수가 이전 테스트를 통과한다고 언급할 수 있습니다. 이 테스트는 함수의 이름과 매개 변수가 올바른지 확인하기 위한 것이었으며, 이제 이 함수의 기본 요구 사항을 캡처하는 테스트를 작성할 수 있다고 설명합니다.

동료와 공동 작업하여 다음 테스트를 작성합니다.

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

팁

이 함수의 경우 먼저 기능에 대한 단위 테스트를 작성한 다음 테스트를 충족하는 코드를 작성하는 테스트 첫 번째 개발을 사용합니다. 다른 경우에는 이 연습이 현실적이지 않으므로 코드를 작성한 후 테스트를 작성합니다. 하지만 코드를 안정적으로 유지하기 때문에 코드 전후에 단위 테스트를 작성하는 것이 매우 중요합니다.

빨간색, 녹색, 리팩터링...

반복적으로 테스트를 작성하고 실패를 확인하고, 테스트를 통과하도록 코드를 작성한 다음, 테스트를 변경하지 않고 코드를 개선하는 리팩터링을 고려하는 주기를 따릅니다.

빨간색

만든 새 테스트를 포함하여 모든 테스트를 실행합니다. 테스트를 작성한 후에는 항상 테스트를 실행하여 통과하도록 만드는 코드를 작성하기 전에 테스트가 실패하는지 확인합니다. 예를 들어 작성한 일부 테스트에 어설션을 배치하는 것을 잊어버린 경우 실패 결과가 표시되면 테스트 결과가 요구 사항이 충족되었음을 올바르게 나타냅니다.

또 다른 유용한 방법은 빌드 후 실행 테스트를 설정하는 것입니다. 이 옵션은 솔루션을 빌드할 때마다 백그라운드에서 테스트를 실행하여 코드의 테스트 상태 대한 지속적인 보고서를 만듭니다. 이 연습으로 인해 Visual Studio의 응답 속도가 느려질 수 있지만 거의 발생하지 않습니다.

테스트에 실패한 테스트 탐색기의 스크린샷.

녹색

개발 중인 메서드의 코드에서 첫 번째 시도를 씁니다.

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

테스트를 다시 실행하고 모든 테스트를 통과합니다.

두 개의 테스트가 통과된 단위 테스트 탐색기의 스크린샷.

리팩터링

이제 코드가 기본 함수를 수행했으므로 코드를 확인하여 더 나은 성능을 제공하는 방법을 찾거나 나중에 더 쉽게 변경할 수 있도록 합니다. 루프에서 수행되는 계산 수를 줄일 수 있습니다.

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

테스트가 계속 통과하는지 확인합니다.

팁

코드를 개발하는 동안 수행하는 모든 변경 내용은 리팩터링 또는 확장이어야 합니다.
- 리팩터링한다는 것은 새 기능을 추가하지 않기 때문에 테스트를 변경하지 않는다는 것을 의미합니다.
- 확장은 테스트를 추가하고 기존 테스트와 새 테스트를 모두 통과하는 데 필요한 코드를 변경하는 것을 의미합니다.
기존 코드를 변경된 요구 사항으로 업데이트하는 경우 더 이상 현재 요구 사항을 나타내지 않는 이전 테스트도 삭제합니다.
이미 통과한 테스트는 변경하지 않습니다. 대신에 새 테스트를 추가합니다. 실제 요구 사항을 나타내는 테스트만 작성합니다.
모든 변경 후 테스트를 실행합니다.

... 반복

간단한 단계 목록을 대략적인 가이드로 사용하여 일련의 확장 및 리팩터링 단계를 계속합니다. 각 확장 후에는 항상 리팩터링 단계를 수행하지 않으며, 경우에 따라 두 개 이상의 리팩터링 단계를 연속적으로 수행합니다. 하지만 코드를 변경할 때마다 항상 단위 테스트를 실행합니다.

경우에 따라 코드를 변경할 필요가 없지만 코드가 올바르게 작동한다는 확신을 주는 테스트를 추가합니다. 예를 들어 함수가 광범위한 입력에서 작동하는지 확인하려고 합니다. 다음과 같은 더 많은 테스트를 작성합니다.

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

이 테스트는 처음 실행되면 통과합니다.

세 번의 테스트를 통과한 테스트 탐색기의 스크린샷.

이 결과가 실수가 아닌지 확인하기 위해 테스트에 작은 오류를 일시적으로 도입하여 실패할 수 있습니다. 오류가 표시되면 다시 해결할 수 있습니다.

팁

테스트를 통과하기 전에 항상 실패합니다.

예외

이제 예외적 입력에 대한 테스트를 작성합니다.

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

이 테스트는 코드를 루프에 넣습니다. 테스트 탐색기에서 취소 단추를 사용해야 합니다. 그러면 10초 이내에 코드가 종료됩니다.

빌드 서버에서 무한 루프가 발생하지 않도록 해야 합니다. 서버가 전체 실행에 시간 제한을 적용하지만 매우 긴 시간 제한이며 상당한 지연이 발생합니다. 따라서 이 테스트에 명시적 시간 제한을 추가할 수 있습니다.

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

명시적 시간 제한으로 인해 테스트가 실패합니다.

이 예외적인 경우를 처리하도록 코드를 업데이트합니다.

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

회귀

새 테스트가 통과하지만 회귀가 있습니다. 이제 통과에 사용된 테스트가 실패합니다.

이전에 통과한 단위 테스트 실패 스크린샷

실수 찾기 및 해결:

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

수정된 후에는 모든 테스트가 다음을 통과합니다.

4개의 테스트가 통과된 단위 테스트 탐색기의 스크린샷

팁

코드를 변경할 때마다 모든 테스트가 통과해야 합니다.

코드 검사

작업하는 동안 간격으로, 마지막으로 코드에서 검사 전에 코드 검사 보고서를 가져옵니다. 이는 테스트에서 실행된 코드의 양을 보여 줍니다.

팀은 최소 80%의 적용 범위를 목표로 합니다. 이러한 유형의 코드에 대해 높은 범위를 달성하기 어려울 수 있으므로 생성된 코드에 대해 이 요구 사항을 완화합니다.

적절한 적용 범위는 구성 요소의 전체 기능이 테스트되었음을 보장하지 않으며 코드가 모든 입력 값 범위에 대해 작동한다고 보장하지는 않습니다. 그럼에도 불구하고 코드 줄의 검사와 구성 요소의 동작 공간 검사 간에는 상당히 긴밀한 상관 관계가 있습니다. 따라서 좋은 커버리지는 팀이 해야 할 대부분의 행동을 테스트하고 있다는 자신감을 강화합니다.

코드 검사 보고서를 얻으려면 Visual Studio 테스트 메뉴에서 모든 테스트에 대한 코드 검사 분석을 선택합니다. 모든 테스트가 다시 실행됩니다.

보고서에서 합계를 확장하면 개발 중인 코드에 전체 적용 범위가 있음을 보여 줄 수 있습니다. 중요한 점수는 테스트 중인 코드에 대한 점수이기 때문에 매우 만족스럽습니다. 발견된 섹션은 실제로 테스트 자체에 있습니다.

코드 검사 색 표시 단추를 전환하여 테스트 코드의 어떤 부분이 실행되지 않았는지 확인할 수 있습니다. 테스트에서 사용되지 않은 코드는 주황색으로 강조 표시됩니다. 그러나 이러한 섹션은 테스트 코드에 있으며 오류가 감지된 경우에만 사용되므로 검사에 중요하지 않습니다.

특정 테스트가 코드의 특정 분기에 도달하는지 확인하려면 코드 검사 색 표시를 설정한 다음 바로 가기 메뉴에서 실행 명령을 사용하여 단일 테스트를 실행할 수 있습니다.

언제 완료되나요?

만족할 때까지 코드를 작은 단계로 계속 업데이트합니다.

사용 가능한 모든 단위 테스트가 통과합니다.

단위 테스트 집합이 매우 큰 프로젝트에서 개발자가 모두 실행될 때까지 기다리는 것은 실용적이지 않을 수 있습니다. 대신, 프로젝트는 제어된 검사 서비스를 운영하며, 원본 트리에 병합되기 전에 각 검사 포함된 선반 집합에 대해 모든 자동화된 테스트가 실행됩니다. 실행이 실패하면 검사 거부됩니다. 이를 통해 개발자는 자체 머신에서 최소 단위 테스트 집합을 실행한 다음 빌드를 중단시킬 위험 없이 다른 작업을 진행할 수 있습니다. 자세한 내용은 제어된 검사 빌드 프로세스를 사용하여 변경 내용의 유효성을 검사합니다.
코드 검사는 팀의 표준을 충족합니다. 75%는 일반적인 프로젝트 요구 사항입니다.
단위 테스트는 일반적인 입력과 예외적 입력을 포함하여 필요한 동작의 모든 측면을 시뮬레이션합니다.
코드를 쉽게 이해하고 확장할 수 있습니다.

이러한 모든 조건이 충족되면 코드를 소스 제어에 검사 준비가 된 것입니다.

단위 테스트를 사용한 코드 개발 원칙

코드를 개발하는 동안 다음 원칙을 적용합니다.

코드와 함께 단위 테스트를 개발하고 개발 중에 자주 실행합니다. 단위 테스트는 구성 요소의 사양을 나타냅니다.
요구 사항이 변경되었거나 테스트가 잘못된 경우가 아니면 단위 테스트를 변경하지 마세요. 코드의 기능을 확장할 때 새 테스트를 점진적으로 추가합니다.
코드의 75% 이상이 테스트에 포함되도록 하는 것을 목표로 합니다. 소스 코드에서 검사 전에 간격으로 코드 검사 결과를 확인합니다.
코드와 함께 단위 테스트를 체크 인하여 연속 또는 일반 서버 빌드에서 실행되도록 합니다.
실제로 각 기능에 대해 단위 테스트를 먼저 작성합니다. 이를 충족하는 코드를 개발하기 전에 이 작업을 수행합니다.

변경 내용 체크 인

변경 내용을 검사 전에 동료와 화면을 다시 공유하여 사용자가 만든 내용을 비공식적으로 대화형으로 검토할 수 있습니다. 테스트는 코드가 작동하는 방식이 아니라 주로 코드가 수행하는 작업에 관심이 있는 동료와 토론의 초점이 됩니다. 이러한 동료는 작성한 내용이 자신의 요구를 충족한다는 데 동의해야 합니다.

테스트와 코드를 포함하여 수행한 모든 변경 내용을 체크 인하고 완료한 작업과 연결합니다. 검사 팀의 자동화된 팀 빌드 시스템을 큐에 추가하여 팀의 CI 빌드 빌드 프로세스를 사용하여 변경 내용의 유효성을 검사합니다. 이 빌드 프로세스를 통해 팀은 개발 컴퓨터와는 별도로 클린 환경에서 팀이 변경한 모든 변경 사항을 빌드하고 테스트하여 코드베이스의 오류를 최소화할 수 있습니다.

빌드가 완료되면 알림이 표시됩니다. 빌드 결과 창에서 빌드가 성공하고 모든 테스트가 통과된 것을 볼 수 있습니다.

변경 내용을 검사

팀 탐색기의 내 작업 페이지에서 체크 인을 선택합니다.
보류 중인 변경 내용 페이지에서 다음을 확인합니다.
- 모든 관련 변경 내용은 포함된 변경 내용에 나열됩니다.
- 모든 관련 작업 항목이 관련 작업 항목에 나열됩니다.
팀이 변경된 파일 및 폴더의 버전 제어 기록을 볼 때 이러한 변경의 목적을 이해하는 데 도움이 되는 설명을 입력합니다.
체크 인 선택합니다.

코드를 지속적으로 통합하려면

연속 통합 빌드 프로세스를 정의하는 방법에 대한 자세한 내용은 CI 빌드 설정을 참조하세요. 이 빌드 프로세스를 설정한 후 팀 빌드 결과에 대한 알림을 받도록 선택할 수 있습니다.

성공적인 빌드가 있는 내 빌드 페이지의 스크린샷.

자세한 내용은 빌드 실행, 모니터링 및 관리를 참조 하세요.

다음 단계

작업 일시 중단, 버그 수정 및 코드 검토 수행

다음을 통해 공유