Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 8개 있습니다.)
VS.NET IDE: 105. Visual Studio의 단위 테스트 작성 시 Fakes를 이용한 메서드 재정의 방법
; https://www.sysnet.pe.kr/2/0/10858

VS.NET IDE: 169. 비주얼 스튜디오 - 단위 테스트 선택 시 MSTestv2 외의 xUnit, NUnit 사용법
; https://www.sysnet.pe.kr/2/0/12726

.NET Framework: 1078. C# 단위 테스트 - MSTestv2/NUnit의 Assert.Inconclusive 사용법(?)
; https://www.sysnet.pe.kr/2/0/12727

.NET Framework: 1079. MSTestv2 단위 테스트에 메서드/클래스/어셈블리 수준의 문맥 제공
; https://www.sysnet.pe.kr/2/0/12728

.NET Framework: 1080. xUnit 단위 테스트에 메서드/클래스 수준의 문맥 제공 - Fixture
; https://www.sysnet.pe.kr/2/0/12729

개발 환경 구성: 590. Visual Studio 2017부터 단위 테스트에 DataRow 특성 지원
; https://www.sysnet.pe.kr/2/0/12749

개발 환경 구성: 593. MSTest - 단위 테스트에 static/instance 유형의 private 멤버 접근 방법
; https://www.sysnet.pe.kr/2/0/12755

.NET Framework: 1084. C# - .NET Core Web API 단위 테스트 방법
; https://www.sysnet.pe.kr/2/0/12756




MSTestv2 단위 테스트에 메서드/클래스/어셈블리 수준의 문맥 제공

그냥 바로 코드를 보는 것이 빠르겠죠? ^^

예를 들기 위해, DLL 프로젝트를 만들어 다음의 코드를 추가한 다음,

using System;

namespace ClassLibrary1
{
    public class Class1
    {
        public int Add(int x, int y)
        {
            return x + y;
        }
    }
}

Add 메서드에 마우스 우클릭을 해 "Create Unit Tests..." 메뉴를 선택, 이어지는 "Create Unit Tests" 창에서는 그냥 기본값으로 두고 "OK" 버튼을 눌러 단위 테스트 프로젝트와 Add 메서드에서 대한 단위 테스트 코드의 뼈대를 생성합니다.

그럼 대충 AddTest 메서드 내의 코드를 다음과 같은 식으로 바꿔 단위 테스트 코드를 완성하게 될 것입니다.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using ClassLibrary1;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ClassLibrary1.Tests
{
    [TestClass()]
    public class Class1Tests
    {
        [TestMethod()]
        public void AddTest()
        {
            Class1 cl = new Class1();
            Assert.AreEqual(4, cl.Add(1, 3));
        }
    }
}

이 상태에서 Add 메서드뿐만 아니라 Subtract를 추가하면,

public class Class1
{
    // ...[생략]...

    public int Subtract(int x, int y)
    {
        return x - y;
    }
}

단위 테스트도 이렇게 만들어 줄 것입니다.

[TestClass()]
public class Class1Tests
{
    // ...[생략]...

    [TestMethod()]
    public void SubtractTest()
    {
        Class1 cl = new Class1();
        Assert.AreEqual(-2, cl.Subtract(1, 3));
    }
}

슬슬 중복 코드가 나오는데요, Class1 cl 인스턴스를 매번 생성해야 하는 것입니다. 혹시 이럴 때 "단위 테스트 메서드" 레벨로 매번 수행하는 코드를 작성하면 되지 않을까요?

바로 그런 목적으로 나온 것이 "[TestInitialize]" 특성입니다. 그래서, 단위 테스트 코드를 다음과 같은 식으로 바꿀 수 있습니다.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using ClassLibrary1;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace ClassLibrary1.Tests
{
    [TestClass()]
    public class Class1Tests
    {
        Class1 _cl;

        [TestInitialize]
        public void Init_Per_Method() // 반드시 public 접근자에 반환 및 인자는 없음
        {
            _cl = new Class1();
        }

        [TestMethod()]
        public void AddTest()
        {
            Assert.AreEqual(4, _cl.Add(1, 3));
        }

        [TestMethod()]
        public void SubtractTest()
        {
            Assert.AreEqual(-2, _cl.Subtract(1, 3));
        }
    }
}

즉, 위와 같은 환경에서 단위 테스트의 실행 순서는 이렇게 됩니다.

Init_Per_Method
    AddTest

Init_Per_Method
    SubtractTest

(우리가 만든 클래스에서는 필요 없지만) 만약 Class1 타입이 IDisposable도 구현했다면,

public class Class1 : IDisposable
{
    // ...[생략]...

    public void Dispose() { /* ... */ }
}

이제 단위 테스트의 메서드마다 수행되는 Cleanup 호출도 있어야 할 것입니다. 그리고 당연히 이것도 TestCleanup 특성을 이용해 제공할 수 있습니다.

[TestClass()]
public class Class1Tests
{
    // ...[생략]...

    [TestCleanup]
    public void Clean_Per_Method() // 반드시 public 접근자에 반환 및 인자는 없음
    {
        _cl.Dispose();
    }
}

예상할 수 있듯이, 이제 실행 순서는 다음과 같게 됩니다.

Init_Per_Method
    AddTest
Clean_Per_Method

Init_Per_Method
    SubtractTest
Clean_Per_Method




그런데, 사실 TestInitialize/TestCleanup이 일반적으로는 크게 필요하지 않습니다. 왜냐하면 이미 단위 테스트를 위한 클래스(위의 경우 Class1Tests)는 메서드 호출마다 새로운 인스턴스가 생성되어 호출이 되기 때문입니다. 실제로 위의 코드는 다음과 같이 변경해도 동일하게 동작합니다.

[TestClass()]
public class Class1Tests : IDisposable
{
    Class1 _cl = new Class1();

    /* 또는,
    public Class1Tests()
    {
        _cl = new Class1();
    }
    */

    public void Dispose()
    {
        _cl.Dispose();
    }

    [TestMethod()]
    public void AddTest()
    {
        Assert.AreEqual(4, _cl.Add(1, 3));
    }

    [TestMethod()]
    public void SubtractTest()
    {
        Assert.AreEqual(-2, _cl.Subtract(1, 3));
    }
}

단지, 몇몇 특수한 사례들이 있는데요, 이에 대해서는 아래의 글에 답변이 나옵니다.

Do you use TestInitialize or the test class constructor to prepare each test? and why?
; https://stackoverflow.com/questions/334515/do-you-use-testinitialize-or-the-test-class-constructor-to-prepare-each-test-an

가령, (아래에서 설명하게 될) TestContext 개체가 Class1Tests 생성자 호출 시점에는 아직 초기화가 안 됐다거나, 생성자는 async 메서드로 만들 수 없지만 TestInitialize 특성이 부여된 메서드는 만들 수 있다는 식의 (거의 사용할 것 같지 않은) 차이만 있습니다.




"단위 테스트 메서드"마다 수행되는 TestInitialize/TestCleanup가 있다면, 당연히 "단위 테스트 클래스"마다 수행되는 특성도 있을 것입니다. 즉, ClassInitialize, ClassCleanup 특성이 바로 그것입니다.

예를 들어, SqlConnection을 클래스 수준에서 공통으로 제공하고 싶다면 다음과 같이 문맥을 제공할 수 있습니다.

[TestClass()]
public class Class1Tests
{
    Class1 _cl;
    static SqlConnection _sqlCon;

    [ClassInitialize]
    public static void Init_Per_Class(TestContext context) // 반드시 public static 접근에, 인자로 TestContext
    {
        _sqlCon = new SqlConnection();
    }

    [ClassCleanup]
    public static void Clean_Per_Class() // 반드시 public static 접근에, 인자 및 반환값 없음
    {
        _sqlCon.Dispose();
    }        

    // ...[생략]...
}

그럼 이제 실행 순서는 다음과 같이 조정이 됩니다.

Init_Per_Class
    Init_Per_Method
        AddTest
    Clean_Per_Method

    Init_Per_Method
        SubtractTest
    Clean_Per_Method
Clean_Per_Class




ClassInitialize 특성이 부여된 메서드의 경우 TestContext 인자를 하나 받는데, 이것은 나중에 보관해 테스트 환경에 대한 정보를 얻고 싶을 때 사용할 수 있습니다.

static TestContext _classContext;

[ClassInitialize]
public static void Init_Per_Class(TestContext context)
{
    _classContext = context;
}

[TestMethod]
public void ExampleTest()
{
    _classContext.WriteLine(_classContext.TestRunDirectory);
}

그런데, ClassInitialize를 사용하지 않는다면 TestContext도 사용할 수 없는 걸까요? 이게 좀 재미있습니다. TestContext도 static과 instance 레벨로 각각 제공되는데요, static 범위는 저렇게 ClassInitialize의 인자로 받지만, instance 레벨의 경우에는 일종의 Property Injection과 같은 방식으로 받게 됩니다.

TestContext _methodContext;

public TestContext TestContext
{
    get { return _testContext; }
    set { _methodContext = value; }
}

여기에는 약간 미묘한 정도의 차이가 있는데요, 가령 다음과 같이 테스트 메서드마다 _classContext를 사용한 경우,

[TestMethod()]
public void AddTest()
{
    Assert.AreEqual(4, _cl.Add(1, 3));
    _classContext.WriteLine($"{_classContext.TestName}, {_classContext.FullyQualifiedTestClassName}");
}

[TestMethod()]
public void SubtractTest()
{
    Assert.AreEqual(-2, _cl.Subtract(1, 3));
    _classContext.WriteLine($"{_classContext.TestName}, {_classContext.FullyQualifiedTestClassName}");
}

개별 메서드 단위로 단위 테스트를 수행했을 때는 다음과 같이 TestContext.WriteLine의 메시지가 잘 나오지만,

vs_unittest_context_1.png

"Run All Tests"로 전체 테스트를 했을 때는 해당 메시지가 나오지 않습니다.

vs_unittest_context_2.png

대신, 위의 경우 첫 번째 테스트에 위치한 "AddTest"의 경우에는 _classContext.WriteLine의 결과가 나옵니다. 이런 이상한 출력 규칙을 해결하려면 (_classContext가 아닌) _methodContext를 사용해야 합니다.

[TestMethod()]
public void AddTest()
{
    Assert.AreEqual(4, _cl.Add(1, 3));
    _methodContext.WriteLine($"{_methodContext.TestName}, {_methodContext.FullyQualifiedTestClassName}");
}

[TestMethod()]
public void SubtractTest()
{
    Assert.AreEqual(-2, _cl.Subtract(1, 3));
    _methodContext.WriteLine($"{_methodContext.TestName}, {_methodContext.FullyQualifiedTestClassName}");
}

엄밀히, "Run All Tests" 시의 Context Message 출력은 _methodContext.WriteLine만 사용하면 됩니다. 하지만, 다른 출력값을 _classContext로 사용하면,

[TestMethod()]
public void AddTest()
{
    Assert.AreEqual(4, _cl.Add(1, 3));
    _methodContext.WriteLine($"{_classContext.TestName}, {_classContext.FullyQualifiedTestClassName}");
}

[TestMethod()]
public void SubtractTest()
{
    Assert.AreEqual(-2, _cl.Subtract(1, 3));
    _methodContext.WriteLine($"{_classContext.TestName}, {_classContext.FullyQualifiedTestClassName}");
}

위와 같은 경우 _methodContext.WriteLine으로 인해 "Run All Tests" 시 모두 결과가 나오지만, _classContext 수준에서는 TestName이 정상적으로 설정이 되지 않아 다음과 같이,

vs_unittest_context_3.png

엉뚱한 결과가 나옵니다. (당연히 AddTest의 MessageContxt만 올바른 결과를 냅니다.) 위와 같은 것을 이해하지 못해서 나오는 질문이 바로 아래와 같은 유형입니다. ^^

Understanding the MSTest TestContext
; https://stackoverflow.com/questions/24249133/understanding-the-mstest-testcontext

현실적으로 봤을 때, 저런 이상한 동작을 고려해 보면 _classContext를 사용할 일은 거의 없을 것 같고, _methodContext로 단일화하는 것이 좋을 것입니다. 게다가 사실 위에서 길게 설명하긴 했지만 TestContext 자체마저도 그다지 쓸 일이 거의 없습니다.

참고로, TestContext의 속성 및 메서드는 다음과 같은 것들이 있습니다.

  • DeploymentDirectory
  • ResultsDirectory
  • TestRunResultsDirectory
  • TestResultsDirectory
  • TestDir
  • TestDeploymentDir
  • TestLogsDir
  • FullyQualifiedTestClassName
  • TestName
  • CurrentTestOutcome
  • AddResultFile(string fileName);
  • WriteLine(string format, params object[] args);




기타, 마지막으로 역시 잘 사용하지는 않지만 어셈블리 수준의 문맥을 제공하는 Init/Clean도 있습니다.

AssemblyInitialize, AssemblyCleanup

이것 역시 ClassInitialize/ClassCleanup과 메서드 signature에 유사한 제약을 갖는데,

[AssemblyInitialize]
public static void Init_Per_Assembly(TestContext context)
{
}

[AssemblyCleanup]
public static void Clean_Per_Assembly()
{
}

거의 쓸 일이 희박할 것 같습니다. ^^

그 외, 관련해서 다음의 도움말을 보면 보다 더 자세한 정보를 얻을 수 있습니다.

Use the MSTest framework in unit tests
; https://learn.microsoft.com/en-us/visualstudio/test/using-microsoft-visualstudio-testtools-unittesting-members-in-unit-tests




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 7/28/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...
NoWriterDateCnt.TitleFile(s)
12564정성태3/16/20217205VS.NET IDE: 160. 새 프로젝트 창에 C++/CLI 프로젝트 템플릿이 없는 경우
12563정성태3/16/20219165개발 환경 구성: 551. C# - JIRA REST API 사용 정리 (3) jira-oauth-cli 도구를 이용한 키 관리
12562정성태3/15/202110320개발 환경 구성: 550. C# - JIRA REST API 사용 정리 (2) JIRA OAuth 토큰으로 API 사용하는 방법파일 다운로드1
12561정성태3/12/20218929VS.NET IDE: 159. Visual Studio에서 개행(\n, \r) 등의 제어 문자를 치환하는 방법 - 정규 표현식 사용
12560정성태3/11/202110203개발 환경 구성: 549. ssh-keygen으로 생성한 개인키/공개키 파일을 각각 PKCS8/PEM 형식으로 변환하는 방법
12559정성태3/11/20219657.NET Framework: 1028. 닷넷 5 환경의 Web API에 OpenAPI 적용을 위한 NSwag 또는 Swashbuckle 패키지 사용 [2]파일 다운로드1
12558정성태3/10/20219155Windows: 192. Power Automate Desktop (Preview) 소개 - Bitvise SSH Client 제어 [1]
12557정성태3/10/20217843Windows: 191. 탐색기의 보안 탭에 있는 "Object name" 경로에 LEFT-TO-RIGHT EMBEDDING 제어 문자가 포함되는 문제
12556정성태3/9/20217073오류 유형: 703. PowerShell ISE의 Debug / Toggle Breakpoint 메뉴가 비활성 상태인 경우
12555정성태3/8/20219118Windows: 190. C# - 레지스트리에 등록된 DigitalProductId로부터 라이선스 키(Product Key)를 알아내는 방법파일 다운로드2
12554정성태3/8/20218909.NET Framework: 1027. 닷넷 응용 프로그램을 위한 PDB 옵션 - full, pdbonly, portable, embedded
12553정성태3/5/20219392개발 환경 구성: 548. 기존 .NET Framework 프로젝트를 .NET Core/5+ 용으로 변환해 주는 upgrade-assistant, try-convert 도구 소개 [4]
12552정성태3/5/20218617개발 환경 구성: 547. github workflow/actions에서 Visual Studio Marketplace 패키지 등록하는 방법
12551정성태3/5/20217538오류 유형: 702. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly. (2)
12550정성태3/5/20217216오류 유형: 701. Live Share 1.0.3713.0 버전을 1.0.3884.0으로 업데이트 이후 ContactServiceModelPackage 오류 발생하는 문제
12549정성태3/4/20217771오류 유형: 700. VsixPublisher를 이용한 등록 시 다양한 오류 유형 해결책
12548정성태3/4/20218545개발 환경 구성: 546. github workflow/actions에서 nuget 패키지 등록하는 방법
12547정성태3/3/20219030오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/20218643개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202111420.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202111617.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/20219946VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202112279개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/20219531개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/20219852.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/20219758Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...