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

비밀번호

댓글 작성자
 




1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13841정성태12/11/20246575오류 유형: 937. error MSB4044: The "ValidateValidArchitecture" task was not given a value for the required parameter "RemoteTarget"
13840정성태12/11/20245795오류 유형: 936. msbuild - Your project file doesn't list 'win' as a "RuntimeIdentifier"
13839정성태12/11/20246871오류 유형: 936. msbuild - error CS1617: Invalid option '12.0' for /langversion. Use '/langversion:?' to list supported values.
13838정성태12/4/20246535오류 유형: 935. Windbg - Breakpoint 0's offset expression evaluation failed.
13837정성태12/3/20247610디버깅 기술: 204. Windbg - 윈도우 핸들 테이블 (3) - Windows 10 이상인 경우
13836정성태12/3/20245699디버깅 기술: 203. Windbg - x64 가상 주소를 물리 주소로 변환 (페이지 크기가 2MB인 경우)
13835정성태12/2/20247512오류 유형: 934. Azure - rm: cannot remove '...': Directory not empty
13834정성태11/29/20247443Windows: 275. C# - CUI 애플리케이션과 Console 윈도우 (Windows 10 미만의 Classic Console 모드인 경우) [1]파일 다운로드1
13833정성태11/29/20246764개발 환경 구성: 737. Azure Web App에서 Scale-out으로 늘어난 리눅스 인스턴스에 SSH 접속하는 방법
13832정성태11/27/20246427Windows: 274. Windows 7부터 도입한 conhost.exe
13831정성태11/27/20245457Linux: 111. eBPF - BPF_MAP_TYPE_PERF_EVENT_ARRAY, BPF_MAP_TYPE_RINGBUF에 대한 다양한 용어들
13830정성태11/25/20247519개발 환경 구성: 736. 파이썬 웹 앱을 Azure App Service에 배포하기
13829정성태11/25/20247509스크립트: 67. 파이썬 - Windows 버전에서 함께 설치되는 py.exe
13828정성태11/25/20245795개발 환경 구성: 735. Azure - 압축 파일을 이용한 web app 배포 시 디렉터리 구분이 안 되는 문제파일 다운로드1
13827정성태11/25/20246764Windows: 273. Windows 환경의 파일 압축 방법 (tar, Compress-Archive)
13826정성태11/21/20247024닷넷: 2313. C# - (비밀번호 등의) Console로부터 입력받을 때 문자열 출력 숨기기(echo 끄기)파일 다운로드1
13825정성태11/21/20247964Linux: 110. eBPF / bpf2go - BPF_RINGBUF_OUTPUT / BPF_MAP_TYPE_RINGBUF 사용법
13824정성태11/20/20245784Linux: 109. eBPF / bpf2go - BPF_PERF_OUTPUT / BPF_MAP_TYPE_PERF_EVENT_ARRAY 사용법
13823정성태11/20/20247446개발 환경 구성: 734. Ubuntu에 docker, kubernetes (k3s) 설치
13822정성태11/20/20247414개발 환경 구성: 733. Windbg - VirtualBox VM의 커널 디버거 연결 시 COM 포트가 없는 경우
13821정성태11/18/20246944Linux: 108. Linux와 Windows의 프로세스/스레드 ID 관리 방식
13820정성태11/18/20247550VS.NET IDE: 195. Visual C++ - C# 프로젝트처럼 CopyToOutputDirectory 항목을 추가하는 방법
13819정성태11/15/20245509Linux: 107. eBPF - libbpf CO-RE의 CONFIG_DEBUG_INFO_BTF 빌드 여부에 대한 의존성
13818정성태11/15/20247518Windows: 272. Windows 11 24H2 - sudo 추가
13817정성태11/14/20246389Linux: 106. eBPF / bpf2go - (BPF_MAP_TYPE_HASH) Map을 이용한 전역 변수 구현
13816정성태11/14/20247653닷넷: 2312. C#, C++ - Windows / Linux 환경의 Thread Name 설정파일 다운로드1
1  2  3  4  5  [6]  7  8  9  10  11  12  13  14  15  ...