Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 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




Visual Studio 2017부터 단위 테스트에 DataRow 특성 지원

아마도 대부분의 단위 테스트가 동일한 메서드에 대한 다양한 입력 값을 넣고 기댓값을 비교하는 것일 듯합니다. (특히나 경곗값 테스트도 그렇고.)

그럴 때, 일일이 "[Test]" 메서드를 작성할 수도 있고 아니면 하나의 테스트 메서드에 몽땅 밀어 넣는 경우도 있을 것입니다. 대개의 경우 권고는 전자의 경우를 따르라고 하지만 그렇게 하면 너무 과다하게 테스트 메서드가 늘어남과 동시에 테스트 자체의 코드에도 중복이 많게 됩니다. 그래서 제 경우에는 후자의 방식을 주로 선호했는데요.

예를 들어, 다음과 같이 GetFirstCharIsUpper라는 메서드를,

using System;

namespace ClassLibrary1
{
    public class Class1
    {
        public string GetFirstCharIsUpper(string text)
        {
            if (char.IsLower(text[0]) == true)
            {
                return text[0] + text.Substring(1);
            }

            return text;
        }
    }
}

테스트하기 위해 이런 식으로 작성하는 것입니다.

using Microsoft.VisualStudio.TestTools.UnitTesting;

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

        [TestMethod()]
        public void GetFirstCharIsUpperTest()
        {
            Assert.IsNull(_cl.GetFirstCharIsUpper(null));
            StringAssert.Equals(string.Empty, _cl.GetFirstCharIsUpper(""));
            StringAssert.Equals("1", _cl.GetFirstCharIsUpper("1"));
            StringAssert.Equals("한글", _cl.GetFirstCharIsUpper("한글"));
            StringAssert.Equals(" test", _cl.GetFirstCharIsUpper(" test"));
            StringAssert.Equals("Test", _cl.GetFirstCharIsUpper("test"));
        }
    }
}

그런데, 이렇게 하면 불편한 점이 있는데 특정 입력 값에서 단위 테스트를 실패하는 경우 다음과 같은 식으로,

mstest_attr_1.png

딱 거기까지만 테스트가 되고 끝나 버린다는 점입니다. 위의 경우 "Assert.IsNull(_cl.GetFirstCharIsUpper(null));" 코드에서 Assert가 발생한 것인데, 사실 두 번째 Assert에서도 문제가 함께 있는데도 그 테스트까지는 진행이 안 된 것입니다. 그래서 저렇게 발생한 오류를 수정하고 다시 한번 단위 테스트를 구동하는 경우 이내 다음번 assert에서 다시 테스트가 실패할 것이고 또 그것을 수정하기를 반복해야 합니다.

바로 이러한 번잡함을 "DataRow" 특성으로 해결할 수 있는데요,

[TestMethod]
[DataRow(null, null)]
[DataRow("", "")]
[DataRow("1", "1")]
[DataRow("한글", "한글")]
[DataRow(" test", " test")]
[DataRow("Test", "test")]
public void GetFirstCharIsUpperTest2(string expected, string arg)
{
    StringAssert.Equals(expected, _cl.GetFirstCharIsUpper(arg));
}

오~~~ 깔끔하죠? ^^ 중복 코드도 많이 없어지고, 게다가 테스트 역시 하나의 항목으로 묶여 관리도 편할뿐더러 DataRow 항목에 대해 모두 실행을 하기 때문에,

mstest_attr_1.png

보는 바와 같이 테스트 실패한 입력 값의 유형을 모두 파악할 수 있어 한 번에 모두 수정하고 다시 단위 테스트를 돌릴 수 있습니다.




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/3/2021]

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

비밀번호

댓글 작성자
 




... 76  77  78  79  80  [81]  82  83  84  85  86  87  88  89  90  ...
NoWriterDateCnt.TitleFile(s)
11911정성태5/23/201917478VS.NET IDE: 136. Visual Studio 2019 - 리눅스 C/C++ 프로젝트에 인텔리센스가 동작하지 않는 경우
11910정성태5/23/201927119Math: 50. C# - MathNet.Numerics의 Matrix(행렬) 연산 [1]파일 다운로드1
11909정성태5/22/201921146.NET Framework: 837. C# - PLplot 사용 예제 [1]파일 다운로드1
11908정성태5/22/201919891.NET Framework: 836. C# - Python range 함수 구현파일 다운로드1
11907정성태5/22/201916610오류 유형: 541. msbuild - MSB4024 The imported project file "...targets" could not be loaded
11906정성태5/21/201916837.NET Framework: 835. .NET Core/C# - 리눅스 syslog에 로그 남기는 방법
11905정성태5/21/201917380.NET Framework: 834. C# - 폴더 경로 문자열에서 "..", "." 표기를 고려한 최종 문자열을 얻는 방법 - 두 번째 이야기
11904정성태5/21/201925771.NET Framework: 833. C# - Open Hardware Monitor를 이용한 CPU 온도 정보 [1]파일 다운로드1
11903정성태5/21/201919590오류 유형: 540. .NET Core - System.PlatformNotSupportedException: The named version of this synchronization primitive is not supported on this platform.
11902정성태5/21/201917753오류 유형: 539. mstest 실행 시 "The directory name is invalid." 오류 발생
11901정성태5/21/201919651오류 유형: 538. msbuild 오류 - Could not find a part of the path '%LOCALAPPDATA%\Temp\2\.NETFramework,Version=v4.0.AssemblyAttributes.cs'
11900정성태5/18/201918602오류 유형: 537. "sfc /scannow" 실행 중 시스템이 부팅되는 현상
11899정성태5/17/201919440Linux: 9. Linux에서 윈도우의 OutputDebugString 대신 사용할 수 있는 syslog [1]
11898정성태5/16/201921249VC++: 130. C++ string의 c_str과 data 함수의 차이점 [3]
11897정성태5/16/201928219오류 유형: 536. Visual Studio - "Developer Pack"을 설치했는데도 "대상 프레임워크" 목록에 나오지 않는 경우 [2]
11896정성태5/15/201923141개발 환경 구성: 440. C#, C++ - double의 Infinity, NaN 표현 방식파일 다운로드1
11895정성태5/12/201921000.NET Framework: 832. ML.NET Model Builder - 회귀(Regression), 다중 분류(Multi-class classification) 예제파일 다운로드1
11894정성태5/10/201922710VS.NET IDE: 135. Visual Studio - ML.NET Model Builder 소개 [5]
11893정성태5/10/201919631오류 유형: 535. C# 6.0 이상의 문법을 컴파일 시 오류가 발생한다면?
11892정성태5/10/201919476웹: 38. HTTP Cookie의 expires 시간 형식(RFC7231)
11891정성태5/9/201922537.NET Framework: 831. (번역글) .NET Internals Cookbook Part 12 - Memory structure, attributes, handles
11890정성태5/8/201917658개발 환경 구성: 439. "Visual Studio Enterprise is required to execute the test." 메시지와 관련된 코드 기록
11889정성태5/8/201918339개발 환경 구성: 438. mstest, QTAgent의 로그 파일 설정 방법
11888정성태5/8/201935706.NET Framework: 830. C# - 비동기 호출을 취소하는 CancellationToken의 간단한 예제 코드 [1]파일 다운로드1
11887정성태5/8/201921316.NET Framework: 829. C# - yield 문을 사용할 수 있는 메서드의 조건
11886정성태5/7/201919160오류 유형: 534. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 [2]
... 76  77  78  79  80  [81]  82  83  84  85  86  87  88  89  90  ...