Azure 솔루션을 효과적으로 테스트하는 방법에 대한 지침

업데이트 날짜: 2015년 1월

저자: Suren Machiraju

검토자: Jaime Alva Bravo 및 Steve Wilkins

Microsoft Azure 솔루션을 설계, 코딩 및 배포 후 작동하지 않는 경우가 종종 있습니다. 이 문서에서는 소프트웨어 개발 주기를 통해 Microsoft Azure 응용 프로그램을 테스트하는 방법에 대한 지침을 제공합니다. 테스트 범위에는 비즈니스 논리 및 포괄적인 종단 간 시나리오 테스트가 포함됩니다. 이 문서에서는 다음과 같은 방법을 시현합니다.

  • Microsoft Azure 구성 요소의 종속성을 제거하면서 비즈니스 논리 구성 요소에 대한 개발 단위 테스트를 진행합니다.

  • 설계 통합 종단 간 테스트를 진행합니다.

  • 매 테스트 실행 시 큐와 같은 Microsoft Azure 서비스 리소스의 설치, 초기화, 정리 및 해제에 대한 오버헤드를 제거합니다.

  • ACS 네임스페이스, 서비스 버스 큐 및 기타 리소스의 인프라를 중복해서 만드는 것을 방지합니다.

추가적으로 이 문서에서는 다양한 테스트 기술과 Microsoft Azure 응용 프로그램의 테스트 기법에 대한 개요를 제공합니다.

이 문서에서 다음과 같은 내용이 새로 변경되었습니다.

  1. Visual Studio 2013을 사용합니다.

  2. Visual Studio 2013에서 Microsoft Fakes가 Moles로 바뀌었습니다. "Microsoft Fakes로 테스트 중 코드 격리" 문서의 이 기능을 설명합니다.

  3. Visual Studio 2013에서 새 버전의 코드 검사를 사용하고 테스트 탐색기에서 바로 호출할 수 있습니다. 자세한 설명은 "테스트할 코드 분량을 결정하기 위해 코드 검사 사용" 문서를 참조하세요.

  4. Pex 팀은 Code Digger라고 하는 Pex의 경량 버전을 릴리스했습니다. 자세한 설명은 "Microsoft Code Digger" 문서를 참조하세요.

  5. Visual Studio 2012를 시작으로 더 이상 전용 메서드 테스트를 권장하지 않습니다. 자세한 설명은 "전용 메서드 단위 테스트"를 참조하세요.

테스트는 두 가지 종류로 나눌 수 있습니다.

  • 단위 테스트는 단일, 특정 기능을 확인하는 좁은 범위의 테스트입니다. 이러한 테스트를 CUT(Code Under Test)라고 합니다. CUT에서 필요로 하는 종속성을 제거해야 합니다.

  • 통합 테스트는 여러 비트의 기능을 동시에 확인하는 범위가 넓은 테스트입니다. 많은 부분에서 단위 테스트와 유사하지만 다양한 기능 영역을 다루고 여러 종속성을 포함합니다.

전반적으로 볼 때 이러한 테스트는 Test Double을 만드는 것과 사용하는 것에 초점을 맞춥니다. 다음 Test Double 종류를 사용합니다.

  • 모조는 개체가 나타내는 것과 동일한 인터페이스를 구현하는 시뮬레이트된 개체입니다. 모조는 미리 정의된 응답을 반환합니다. 모조에는 일련의 메소드 스텁이 포함되어 있으며 프로그래밍 방식으로 빌드한 것을 대체하는 역할을 합니다.

  • 스텁은 소프트웨어 개체의 동작을 시뮬레이션합니다.

  • Shim은 솔루션의 한 부분이 아닌 어셈블리에서 코드를 격리할 수 있도록 합니다. 각각의 솔루션 구성 요소도 격리합니다.

일단 실행되면 이러한 테스트는 상태 및 동작을 확인할 수 있습니다. 예를 들어, 상태는 메서드를 호출하고 특정 값을 반환한 후의 결과를 포함합니다. 동작의 한 가지 예는 특정 순서 또는 횟수에서 메서드를 호출하는 것입니다.

단위 테스트의 주요 목표 중 하나는 종속성을 제거하는 것입니다. Azure 프레임워크에서 이러한 종속성은 다음을 포함합니다.

  • 서비스 버스 큐

  • 액세스 제어 서비스

  • 캐시

  • Azure 테이블, Blob 및 큐

  • Azure SQL 데이터베이스

  • Azure 드라이브(이전 클라우드 드라이브)

  • 다른 웹 서비스

Azure 응용 프로그램용 테스트를 빌드할 때 논리 연습에서 테스트에 초점을 맞추기 위해 이러한 종속성을 바꿉니다.

이 문서에서 다룰 서비스 버스 큐 예(도구 및 기술 포함)도 다른 모든 종속성에 적용됩니다.

Microsoft Azure 응용 프로그램에 테스트 프레임워크를 구현하려면 다음이 필요합니다.

  • 테스트를 정의하고 실행할 단위 테스트 프레임워크가 필요합니다.

  • 종속성을 격리시키고 좁은 범위의 단위 테스트를 빌드하게 해주는 모의 프레임워크가 필요합니다.

  • 자동 단위 테스트 생성 기능으로 증가한 코드 검사를 처리해주는 도구가 필요합니다.

  • 테스트 가능한 설계로 종속성 삽입의 이점을 취하고 IoC(Inversion of Control) 패턴을 적용하는 다른 프레임워크가 필요합니다.

Visual Studio에는 MS Test라고 하는 명령줄 유틸리티가 포함되어 있으며 Visual Studio에서 만든 단위 테스트를 실행합니다. Visual Studio에는 테스트를 지원할 프로젝트와 항목 템플릿 모음도 포함되어 있습니다. 일반적으로 테스트 프로젝트를 만든 다음 [TestClass] 특성을 적용한 클래스(테스트 설비로 알려짐)를 추가합니다. 클래스에는 [TestMethod] 특성을 적용한 메서드가 포함되어 있습니다. MS Test에서 다양한 Visual Studio 창을 사용하여 프로젝트에 정의된 단위 테스트를 실행할 수 있습니다. 실행 후 결과를 검토할 수도 있습니다.

note참고
Visual Studio 2013 Express, Professional 및 Test Professional Edition에는 MS Test가 포함되어 있지 않습니다.

MS Test에서 단위 테스트는 AAA 패턴이라고 하는 Arrange, Act 및 Assert를 따릅니다.

  • Arrange - CUT가 필요로 하는 필수 구성 요소 개체, 구성 및 필요한 다른 모든 사전 조건을 빌드합니다.

  • Act - 코드에서 실제적이고 범위가 좁은 테스트를 수행합니다.

  • Assert - 예상했던 결과가 나왔는지 확인합니다.

MS Test 프레임워크 라이브러리에는 PrivateObjectPrivateType 도우미 클래스가 포함됩니다. 이러한 클래스는 리플렉션을 사용하여 단위 테스트 코드에서 public이 아닌 인스턴스 멤버나 정적 멤버를 쉽게 호출할 수 있도록 합니다.

Visual Studio Premium 및 Ultimate Edition에는 향상된 단위 테스트 도구가 포함되어 있습니다. 이러한 도구는 MS Test와 통합됩니다. 도구에서는 단위 테스트가 실행하는 코드 분량도 분석할 수 있습니다. 추가적으로 도구에서는 검사할 소스 코드를 색 코드로 나타냅니다. 이 기능을 코드 검사라고 합니다.

단위 테스트의 목표는 격리된 상태에서 테스트하는 것입니다. 그러나 격리 상태에서 CUT를 테스트할 수 없는 경우가 종종 있습니다. 테스트를 할 수 없도록 코드가 작성되기도 합니다. 코드는 쉽게 격리할 수 없는 다른 라이브러리에 의존하고 있어 다시 작성하기가 힘듭니다. 예를 들어, 외부 환경과 상호 작용을 하는 코드는 쉽게 격리시킬 수 없습니다. 모의 프레임워크를 사용하여 양쪽 종류의 종속성을 격리시킬 수 있습니다.

고려해야 할 모의 프레임워크 목록은 이 문서 끝에 있는 링크 섹션에서 볼 수 있습니다. 이 문서에서는 Microsoft Fakes를 사용하는 방법에 초점을 맞춥니다.

Microsoft Fakes는 테스트하는 코드를 스텁 또는 Shim을 사용하여 응용 프로그램의 다른 부분으로 바꿔 격리시킬 수 있습니다. 코드의 작은 부분으로 테스트에서 제어합니다. 테스트를 위해 코드를 격리시킨 다음 테스트에 실패했으면 격리된 코드에서 원인을 찾을 수 있습니다. 응용 프로그램의 다른 부분이 작동하지 않아도 스텁과 Shim을 사용해 코드를 테스트할 수 있습니다.

Fake의 두 가지 형태는 다음과 같습니다.

  • 스텁은 동일한 인터페이스를 구현하는 작은 대체 항목으로 클래스를 바꿉니다. 스텁을 사용하려면 각 구성 요소가 인터페이스만 의존하고 다른 구성 요소를 의존하지 않도록 응용 프로그램을 설계해야 합니다. "구성 요소"는 클래스 또는 클래스 그룹을 의미하며 같이 설계 및 업데이트되었고 일반적으로 어셈블리에 포함되어 있습니다.

  • Shim은 런타임에서 응용 프로그램의 컴파일된 코드를 수정합니다. 지정한 메서드를 호출하지 않고 응용 프로그램은 테스트에서 제공하는 Shim 코드를 실행합니다. .NET 어셈블리처럼 수정할 수 없는 어셈블리 호출을 대체하기 위해 Shim을 사용합니다.

Code Digger는 .NET 코드를 통해 가능한 실행 경로를 분석합니다. 결과는 각 행이 코드의 고유한 동작을 표시하는 테이블로 나타납니다. 테이블을 통해 코드의 동작 원리를 이해할 수 있으며 숨겨진 버그를 찾는 데도 활용됩니다.

Visual Studio 편집기에서 코드를 분석하려면 Code Digger를 호출하는 새로운 상황에 맞는 메뉴 항목인 입출력 테이블 생성을 사용하세요. Code Digger는 입력-출력 쌍을 계산하고 표시합니다. Code Digger는 시스템적인 방법으로 버그, 예외 및 어설션 실패를 해결합니다.

기본적으로 Code Digger는 휴대용 클래스 라이브러리에 위치한 공용 .NET 코드에서만 동작합니다. 이 문서의 후반부에서 다른 .NET 프로젝트를 탐색하기 위해 Code Digger를 구성하는 방법을 살펴볼 것입니다.

Code Digger는 Pex 엔진 및 Microsoft Research Z3 제한 해결사를 사용하여 시스템적인 방법으로 코드의 모든 부분을 분석합니다. Code Digger는 코드를 세부적으로 검사할 수 있도록 테스트 모음 생성을 시도합니다.

Microsoft Unity를 사용하여 DI(Dependency Injection) 및 IoC(Inversion of Control) 컨테이너를 확장할 수 있습니다. 인터셉션, 생성자 삽입, 속성 삽입 및 메서드 호출 삽입을 지원합니다. Microsoft Unity 및 유사한 도구를 사용하면 응용 프로그램의 모든 수준에서 종속성을 삽입하고 테스트 가능 설계를 빌드할 수 있습니다. 응용 프로그램이 종속성 삽입 및 이러한 프레임워크 중 하나로 설계되고 구축되었다고 가정합니다.

이러한 프레임워크는 테스트 가능한 코드를 작성하고 궁극적으로는 뛰어난 코드를 만드는 데 아주 유리합니다. 그러나 이것들은 선행 설계 요구 사항에서 요구될 수 있습니다. 이 문서에서는 DI 및 IoC 컨테이너를 다루지 않습니다.

이 섹션은 웹 역할에서 호스트되는 웹 사이트를 포함하는 솔루션을 설명합니다. 웹 사이트에서 큐로 메시지를 보냅니다. 그런 다음 작업자 역할이 큐에서 메시지를 처리합니다. 세 가지 테스트 요소 모두를 살펴보겠습니다.

주문을 받는 웹 사이트를 운영하고 있으며 서비스 버스 큐는 이러한 주문을 처리하는 큐를 만든다고 가정해 봅시다. 웹 페이지 모양은 그림 1과 같을 것입니다.

그림 1

그림 1

사용자가 만들기를 클릭하면 서비스 버스 큐는 연결된 컨트롤러의 작업 만들기에 새 주문을 게시합니다. 이 작업은 다음과 같이 구현됩니다.

note참고
MicrosoftAzureQueue 클래스는 서비스 버스 큐와 상호 작용하기 위해 MessageSender 및 MessageReceiver와 같은 서비스 버스 .NET API를 사용하는 래퍼 클래스입니다.

private IMicrosoftAzureQueue queue;
public OrderController()
{
    queue = new MicrosoftAzureQueue();
}
public OrderController(IMicrosoftAzureQueue queue)
{
    this.queue = queue;
}
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Create([Bind(Include = "OrderId,Description")] Order order)
{
    try
    {
        if (ModelState.IsValid)
        {
            string connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");
            string queueName = "ProcessingQueue";
            queue.InitializeFromConnectionString(connectionString, queueName);
            queue.Send(order);
        }
        return View("OrderCreated");
    }
    catch (Exception ex)
    {
        Trace.TraceError(ex.Message);
        return View("Error");
    }            
}

코드는 CloudConfigurationManager에서 구성 설정을 검색하고 주문이 포함된 메시지를 큐로 전송합니다. 또한 만들기 작업은 다음 메서드를 사용합니다.

  • InitializeFromConnectionString(ConnectionString 문자열, QueueName 문자열)

  • Send(MicrosoftAzureQueue 클래스)

동작을 제어하고 실제 환경에서 종속성을 제거하기 위해 모조를 사용해 이러한 메서드의 우회 수단을 구축하려고 합니다. 모조를 사용하여 Azure 에뮬레이터에서 테스트 실행 요구를 제거하거나 서비스 버스 큐를 호출합니다. 입력한 주문이 큐로 전송한 주문인지 확인하기 위해 컨트롤러에서 만들기 작업을 실행합니다. Send 메서드는 입력 작업을 할 때 입력한 내용에 주문 ID와 설명이 있는지 확인합니다. 그런 다음 OrderCreated 보기가 결과로 나타나는지 확인합니다.

모조를 사용하여 위 구현에 대한 단위 테스트를 쉽게 구축할 수 있습니다. 테스트 프로젝트에서 모의로 진행하려면 종류가 포함된 어셈블리를 마우스 오른쪽 단추로 클릭합니다. 그런 다음 모조 어셈블리 추가를 선택합니다.

예에서는 Microsoft.ServiceBus를 선택한 다음 모조 어셈블리 추가를 선택했습니다. “Microsoft.ServiceBus.Fakes”라는 이름의 XML 파일이 테스트 프로젝트에 추가됩니다. Microsoft.WindowsAzure.Configuration 어셈블리에 대해서도 작업을 반복합니다.

테스트 프로젝트를 빌드할 때 참조가 이러한 어셈블리의 자동 생성된 모의 버전에 추가됩니다. 예에서 생성된 어셈블리는 “Microsoft.ServiceBus.Fakes” 및 “Microsoft.WindowsAzure.Configuration”입니다.

단위 테스트 메서드를 만들고 [TestCategory("With fakes")] 특성을 적용합니다. 단위 테스트에서 Shim을 사용하여 각각의 응용 프로그램을 격리시킬 수 있습니다.

단위 테스트를 위해 Shim을 사용하여 응용 프로그램을 다른 어셈블리에서 격리

Shim은 테스트 중인 구성 요소를 환경으로부터 쉽게 격리시킬 수 있는 Microsoft Fakes 프레임워크의 두 가지 기술 중 하나입니다. Shim은 테스트의 일부로 작성한 코드에 대한 특정 메서드의 호출을 우회시킵니다. 많은 메서드가 외부 조건에 따라 다른 결과를 반환합니다. 그러나 shim은 테스트에서 제어하고 있으므로 모든 호출에 대해 일관된 결과를 반환할 수 있습니다. 이를 통해 테스트를 더욱 쉽게 기록할 수 있습니다. Shim을 사용하여 솔루션의 한 부분이 아닌 어셈블리에서 코드를 격리시킬 수 있습니다. 솔루션의 구성 요소를 각각 격리시키려면 스텁을 사용하는 것이 좋습니다.

단위 테스트를 위해 스텁을 사용하여 각 응용 프로그램의 일부를 격리

스텁은 테스트 중인 구성 요소를 다른 구성 요소와 쉽게 격리시키는 Microsoft Fakes 프레임워크의 두 가지 기술 중 하나입니다. 스텁은 작은 코드로 테스트 중 다른 구성 요소에 위치합니다. 스텁을 사용하면 일관된 결과를 반환하므로 테스트를 쉽게 기록할 수 있습니다. 추가적으로 다른 구성 요소가 동작하지 않을 때도 테스트를 진행할 수 있습니다.

현재 테스트에서는 Shim을 Azure 어셈블리의 CloudConfigurationManager 및 BrokeredMessage에 사용합니다. 스텁을 솔루션의 클래스인 MicrosoftAzureQueue에 사용합니다.

[TestMethod]
[TestCategory("With fakes")]
public void Test_Home_CreateOrder()
{
    // Shims can be used only in a ShimsContext
    using (ShimsContext.Create())
    {
        // Arrange
        // Use shim for CloudConfigurationManager.GetSetting
        Microsoft.WindowsAzure.Fakes.ShimCloudConfigurationManager.GetSettingString = (key) =>
        {
            return "mockedSettingValue";
        };
                
        // Create the fake queue:
        // In the completed application, queue would be a real one:
        bool wasCreateFromConnString = false;
        Order orderSent = null;
        IMicrosoftAzureQueue queue =
                new OrderWebRole.Queue.Fakes.StubIMicrosoftAzureQueue() // Generated by Fakes.
                {
                    // Define each method:
                    // Name is original name + parameter types:
                    InitializeFromConnectionStringStringString = (connectionString, queueName) => {
                        wasCreateFromConnString = true;
                    },
                    SendOrder = (order) => {
                    orderSent = order;
                    }
                };

        // Component under test
        OrderController controller = new OrderController(queue);

        // Act
        Order inputOrder = new Order()
        {
            OrderId = System.Guid.NewGuid(),
            Description = "A mock order"
        };
        ViewResult result = controller.Create(inputOrder) as ViewResult;

        //Assert
        Assert.IsTrue(wasCreateFromConnString);
        Assert.AreEqual("OrderCreated", result.ViewName);
        Assert.IsNotNull(orderSent);
        Assert.AreEqual(inputOrder.OrderId, orderSent.OrderId);
        Assert.AreEqual(inputOrder.Description, orderSent.Description);
    }
}

웹 역할은 큐에 추가되는 주문을 관리합니다. 이제 서비스 버스 큐에서 주문을 검색하여 처리하는 작업자 역할을 테스트하는 방법을 살펴 보겠습니다. 작업자 역할의 Run 메서드는 주문이 전송되는 큐에 주기적으로 폴링하여 주문이 있는 경우 이를 처리합니다.

private IMicrosoftAzureQueue queue;
public WorkerRole()
{
    queue = new MicrosoftAzureQueue();
}

public WorkerRole(IMicrosoftAzureQueue queue)
{
    this.queue = queue;
}
public override void Run()
{
    try
    {
        string connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");
        string queueName = "ProcessingQueue";
               
        queue.InitializeFromConnectionString(connectionString, queueName);
            
        queue.CreateQueueIfNotExists();
              
        while (true)
        {
            Thread.Sleep(2000);
            //Retrieve order from Service Bus Queue  
            TryProcessOrder(queue);
        }
    }
    catch (Exception ex)
    {
        if (queue != null)
            queue.Close();
        System.Diagnostics.Trace.TraceError(ex.Message);
    }
}

메시지를 올바르게 검색했는지 루틴을 확인하려고 합니다. 다음은 작업자 역할의 Run 메서드에 대한 전체 단위 테스트입니다.

[TestMethod]
public void Test_WorkerRole_Run()
{
    // Shims can be used only in a ShimsContext:
    using (ShimsContext.Create())
    {
        Microsoft.WindowsAzure.Fakes.ShimCloudConfigurationManager.GetSettingString = (key) =>
        {
            return "mockedSettingValue";
        };

        // Arrange 
        bool wasEnsureQueueExistsCalled = false;
        int numCallsToEnsureQueueExists = 0;

        // Create the fake queue:
        // In the completed application, queue would be a real one:
        bool wasConnectionClosedCalled = false;
        bool wasCreateFromConnString = false;
        bool wasReceiveCalled = false;
        int numCallsToReceive = 0;

        bool wasCompleteCalled = false;
        int numCallsToComplete = 0;
        IMicrosoftAzureQueue queue =
                new OrderWebRole.Queue.Fakes.StubIMicrosoftAzureQueue() // Generated by Fakes.
                {

                    // Define each method:
                    // Name is original name + parameter types:
                    InitializeFromConnectionStringStringString = (connectionString, queueName) =>
                    {
                        wasCreateFromConnString = true;
                    },
                    CreateQueueIfNotExists = () =>
                    {
                        wasEnsureQueueExistsCalled = true;
                        numCallsToEnsureQueueExists++;
                    },
                    Receive = () =>
                {
                    wasReceiveCalled = true;
                    if (numCallsToReceive >= 3) throw new Exception("Aborting Run");
                    numCallsToReceive++;
                    Order inputOrder = new Order()
                    {
                        OrderId = System.Guid.NewGuid(),
                        Description = "A mock order"
                    };
                    return new BrokeredMessage(inputOrder);
                },
                    Close = () =>
                    {
                        wasConnectionClosedCalled = true;
                    }

                };


        Microsoft.ServiceBus.Messaging.Fakes.ShimBrokeredMessage.AllInstances.Complete = (message) =>
        {
            wasCompleteCalled = true;
            numCallsToComplete++;
        };

        WorkerRole workerRole = new WorkerRole(queue);

        //Act
        workerRole.Run();

        //Assert
        Assert.IsTrue(wasCreateFromConnString);
        Assert.IsTrue(wasConnectionClosedCalled);
        Assert.IsTrue(wasEnsureQueueExistsCalled);
        Assert.IsTrue(wasReceiveCalled);
        Assert.AreEqual(1, numCallsToEnsureQueueExists);
        Assert.IsTrue(numCallsToReceive > 0);
        Assert.IsTrue(wasCompleteCalled);
        Assert.IsTrue(numCallsToComplete > 0);
        Assert.AreEqual(numCallsToReceive, numCallsToComplete);

    }
}

생성된 모조 종류에 대한 AllInstances 속성의 대리자를 설정해야 합니다. 대리자를 사용하면 실제 모조 종류로 만든 인스턴스는 정의한 대리자가 있는 메서드를 통해 우회할 수 있습니다.

예에서 원래 인스턴스의 Run 메서드를 사용하려고 했지만 CreateQueueTryProcessOrder 인스턴스 메서드의 우회가 제공됩니다. 코드에서 예외를 두어 미리 결정한 시간에 Run 메서드가 유지하는 무한 루프를 종료할 수 있도록 합니다.

도우미 종류를 삽입하는 대신 MessageSender/MessageReceiver 및 서비스 버스 SDK의 관련 클래스를 직접 사용하지 않는 이유가 무엇일까요? 코드를 완전히 격리시켜 실제 서비스 버스를 호출하지 않도록 하려면 다음 두 가지 방법을 사용하면 됩니다.

  • Microsoft.ServiceBus 네임스페이스에서 추상 클래스를 상속하는 모조를 작성합니다.

  • 모조가 모든 항목에 대한 모의 종류를 만들도록 합니다.

각 접근 방법에 대한 문제는 복잡성입니다. 두 접근 방법으로 TokenProviderQueueClient와 같은 클래스에 확실하게 반영할 수 있습니다. 반영하면 다음 문제가 발생할 수 있습니다.

  • 필요한 모든 재정의를 표시하는 추상 종류에서 파생된 종류를 만들어야 합니다.

  • 이러한 클래스가 의존하고 있는 실제 버전의 내부 종류를 표시해야 합니다.

  • 내부 종류의 경우, 실제 서비스 버스에서 종속성을 연습하기 위해 적절한 방법으로 생성자나 출하 시 메서드를 다시 만들어야 합니다.

더 나은 옵션은 자신의 도우미 종류를 삽입하는 것입니다. 이것이 실제 서비스 버스에서 코드를 모의로 작업하고, 우회하며, 격리시키는 데 필요한 모든 것입니다.

단위 테스트로 확인한 것이 무엇인지 분석하기 위해 코드 검사 데이터를 조사할 수 있습니다. MS Test를 사용하여 두 단위 테스트를 실행하면 모두 통과하게 됩니다. 테스트 탐색기 대화 상자에서 관련된 실행 세부 정보도 볼 수 있습니다.

그림 2

그림 2

테스트 탐색기에서 현재 테스트에 대한 코드 검사를 실행할 수 있습니다. 테스트를 마우스 오른쪽 단추로 클릭하고 선택한 테스트의 코드 검사 분석을 선택합니다. 결과가 코드 검사 결과 창에 표시됩니다. 코드 검사의 데이터 컬렉션을 활성화하려면 솔루션 항목에서 Local.testsettings 파일을 구성합니다. 이 파일을 열면 테스트 설정 편집기가 시작됩니다.

Local.testsettings 파일에 포함되지 않은 솔루션이 있으면 다음 절차에 따라 솔루션에 추가합니다.

  1. 새 항목 추가 단추를 클릭합니다.

  2. 테스트를 선택한 다음 테스트 설정을 클릭합니다.

    그림 3
    그림 3

  3. 데이터 및 진단 탭을 클릭하고 코드 검사 행 오른쪽에 있는 확인란을 선택합니다.

  4. 다음으로 구성 단추 그림 A를 클릭합니다.

  5. 코드 검사 세부 정보 창에서 테스트할 어셈블리를 모두 선택하고 확인을 클릭합니다.

    그림 4
    그림 4

  6. 테스트 설정 편집기를 닫으려면 적용 및 닫기를 클릭합니다.

  7. 테스트를 다시 실행하고 코드 검사 단추를 누릅니다. 코드 검사 결과가 그림 5와 비슷하게 나타납니다.

    그림 5
    그림 5

  8. 코드 검사 색 표시 아이콘을 클릭한 다음 표에서 메서드를 탐색합니다.

  9. 메서드를 두 번 클릭합니다. 테스트한 영역은 다른 색으로 표시된 소스 코드가 나타납니다. 코드에서 테스트한 부분은 녹색으로 표시됩니다. 회색은 부분적으로 테스트했거나 아직 테스트하지 않은 코드를 나타냅니다.

    그림 6
    그림 6

단위 테스트를 수동으로 만드는 작업도 중요하지만 Code Digger를 사용하면 단위 테스트를 지능적으로 업그레이드할 수 있습니다. 고려할 필요가 없는 매개 변수 값으로 시도할 수 있습니다. Code Digger를 설치한 후 코드 편집기에서 메서드를 마우스 오른쪽 단추로 클릭해 탐색한 후 입출력 테이블 생성을 선택합니다.

그림 7

그림 7

잠시 후, Code Digger가 작업을 마칩니다. 그리고 안정적인 결과가 표시됩니다. 예를 들어, 그림 8은 작업자 역할의 TryProcessOrder 메서드에서 Code Digger 실행 결과를 보여 줍니다. Code Digger는 결과가 예외 처리되는 테스트를 만들 수 있습니다. Code Digger는 예외를 생성하기 위해 만들어진 중요한 입력 내용도 표시합니다(큐 매개 변수의 Null 값).

그림 8

그림 8

표시: