[C#/NUnit] NUnit 테스트 전후 처리, SetUpAttribute & TearDownAttribute

반복되는 마무리 처리

오늘, 단위 테스트를 진행하다가 난감한 상황을 맞닥뜨렸습니다.
단위 테스트 대상 메서드는 ADB를 통해 특정 작업을 시행한 뒤 Redirect된 출력을 바탕으로 내용을 분석해 원하는 결과가 나왔는지 체크하는 메서드였는데요.
문제는, ADB 프로세스를 처음 실행할 때, 데몬 모드로 프로세스가 꺼지지 않게 계속 실행된다는 것입니다.
이 문제를 해결하기 위해서, 여러 시도를 했습니다. 우선, 매 adb 명령이 완료될 때마다 프로세스 리스트에서 adb를 모두 종료하는 방식이 첫번째였죠. 하지만, 이 경우에 ADB 작업이 실행될 때마다 데몬이 켜지길 반복하기 때문에, 심각할 정도의 CPU 자원 낭비, 즉 딜레이가 생겼습니다.
그래서, ADB 관련 처리를 하는 클래스에 IDisposable을 구현한 뒤, Dispose() 메서드에서 전체 adb 프로세스를 죽이는 작업을 처리하도록 했습니다. 이러면 아래와 같이 사용할 수 있죠.
using (var manager = new AdbManager())
{
    // TODO: Process...
}
실사용에선 별 문제가 없어 보입니다. 그렇지만, 고작 단위 테스트 하나를 위해서 저렇게 해야될까요? 당연히 아닙니다. 제가 사용하는 NUnit 테스트 프레임워크엔 이럴 경우를 위한 어트리뷰트가 마련돼 있습니다. 물론, 다른 프레임워크도 비슷한 기능이 있으나, 이번에 제가 포스팅할 것은 제가 사용하는 NUnit에 대해서입니다.

SetUpAttribute, TearDownAttribute

바로 SetUpAttribute와 TearDownAttribute입니다. 각각 단위 테스트를 시작하기 전, 그리고 단위 테스트를 마친 후 시행될 작업을 정의할 메서드에 붙여주시면 됩니다.
지금 제 상황에 맞게 코딩해볼까요?
[TestFixture]
public class AdbManagerTests
{
    // 다른 수많은 비슷한 테스트 메서드들...

    [Test]
    public void GetCurrentNetworkStatusTest()
    {
        // adb shell dumpsys telephony.registry 출력에 따라 현재 모바일 연결 상태를 가져옴
        // adb shell su -c dumpsys wifi 출력에 따라 현재 와이파이 연결 상태를 가져옴

        // 작업 진행 중 Assert 예외 발생
        Assert.IsTrue(false);

        // 다른 수많은 테스트...

        // 테스트 종료
    }

    // 다른 수많은 비슷한 테스트 메서드들...

    // 모든 테스트가 완료된 뒤 남아있는 adb 프로세스 정리
    [TearDown] // 이 메서드를 모든 테스트가 완료된 뒤 시행하겠다는 의미의 Attribute
    public void Cleanup()
    {
        Process.GetProcessesByName("adb").ToList().ForEach(p => p.Kill());
    }
}
이 경우, AdbManagerTests 테스트 픽스쳐에 대해 단위 태스트를 진행하면, 아래와 같이 처리가 됩니다.
  1. 수많은 문제 없는 단위 테스트가 성공
  2. GetCurrentNetworkoStatusTest 단위 테스트 실행
    1. Assert.IsTrue(false); 실행
    2. Assert.IsTrue(false); 에서 예외 발생
  3. 다른 수많은 문제없는 단위 테스트가 성공
  4. Cleanup 메서드 실행
    1. 모든 adb 프로세스가 종료됨.
즉, 모든 테스트가 완료된 뒤, 예외 발생에 상관없이 Cleanup 메서드가 실행됩니다.
SetUpAttribute도 같은 방식으로 생각하시면 됩니다. 모든 테스트가 시작되기 전 실행되는 메서드를 지정하는 것이죠.
[TestFixture]
public class AdbManagerTests
{
    // 모든 테스트 메서드가 실행되기 전, ADB를 인터넷으로부터 다운로드
    [SetUp]// 이 메서드를 모든 테스트 메서드가 실행되기 전에 실행시키겠다는 어트리뷰트
    public void Init()
    {
        DownloadAdbFromInternet();
    }
    // 다른 수많은 비슷한 테스트 메서드들...

    [Test]
    public void GetCurrentNetworkStatusTest()
    {
        // adb shell dumpsys telephony.registry 출력에 따라 현재 모바일 연결 상태를 가져옴
        // adb shell su -c dumpsys wifi 출력에 따라 현재 와이파이 연결 상태를 가져옴

        // 작업 진행 중 Assert 예외 발생
        Assert.IsTrue(false);

        // 다른 수많은 테스트...

        // 테스트 종료
    }

    // 다른 수많은 비슷한 테스트 메서드들...
아, 혹시 몰라 말씀드리지만, SetUpAttribute나 TearDownAttribute가 붙어있다면 테스트 픽스쳐 내 메서드 순서와 상관없이 맨 처음, 혹은 맨 마지막에 실행됩니다. 그러나, 나중에 알아보기 편하려면 SetUpAttribute가 붙은 메서드는 맨 위에, TearDownAttribute가 붙은 메서드는 맨 아래, 혹은 SetUpAttribute가 붙은 메서드 바로 밑에 붙이는 등 본인의 규칙대로 정렬하는 게 좋겠죠?
더 자세한 설명은 영어가 되신다면 이 링크에서 보실 수 있습니다.
​

댓글

댓글 쓰기

이 블로그의 인기 게시물

C# 남아도는 메모리에도 불구하고 OutOfMemoryException이 발생한다면?

이미지
  C# 코딩 중 평소 볼 수 없던 생소한 현상이 발생했습니다. 분명 메모리는 남아도는데(32기가바이트 중 26기가바이트 사용 가능) 프로그램이 돌다가 OutOfMemory 예외를 던지며 죽어버리는 현상이었죠. List 에 수많은 파싱된 데이터를 넣는 작업 중이었습니다.   그래서 메모리 프로파일러를 잘 관찰해보니 2GB의 메모리를 사용하면 무조건 뻗어버리는 현상을 발견했고, 왜 그럴까 생각해보다가 문득 예전 XP에서 4기가 메모리를 달아도 32비트 운영체제의 한계 아닌 한계로 3기가 조금 넘게밖에 인식을 못 했던 것이 생각났습니다. 생각은 자연스럽게 컴파일이 32비트로 됐구나! 쪽으로 넘어갔고 프로젝트 설정에 보니 빌드 항목에 해당되는 체크박스가 있더군요.   현재 메모리가 남아도는데도 OutOfMemory 예외가 뜬다면 100% 저게 체크된 상태일 겁니다. 그림과 같이 체크 해제 하신 후 실행하시면 특별한 경우가 아닌 이상 컴퓨터 메모리가 바닥날 때까지 저 예외를 볼 일 없게 될겁니다.
자세한 내용 보기

USB를 뒤는 괜찮은데 앞에 꽂으면 인식이 힘들다?

이미지
USB 장치 인식 실패   보기만 해도 짜증나는 제목이죠. USB 장치 인식 실패. 원인은 여러가지가 있을 수 있습니다. USB 컨트롤러가 고장이거나, USB 케이블이 단선됐거나, 전원 공급이 원활하지 않거나. 하지만 뒷쪽에 꽂으면 괜찮은데 앞에 꽂으면 USB 장치 인식을 실패한다면? 십중팔구 전원 문제입니다. 불안정한 전원 공급   본체 앞쪽에 달려 있는 USB 포트는 메인보드에 다이렉트로 붙어 있는 뒷쪽과 달리 메인보드에서 케이블 하나를 거쳐 전면 패널에 연결 됩니다. 게다가, 이 케이블과 연결되는 메인보드의 부분은 주로 메인보드에 전원이 연결되는 부분과 정 반대쪽에 있기 때문에 , 저가형 불량 메인보드에선 아예 회로 자체가 잘못돼 전원이 제대로 전달되지 않는 경우도 있습니다.   이렇게 메인보드 자체의 문제일 경우엔 어쩔 수 없지만, 그게 아니라면 몇 가지 시도해 볼 수 있는 방법이 있습니다. USB 포트 청소   전원 공급이 불안정한 이유 중 하나가 될 수 있는 포트 내부의 먼지. 접촉 단자 사이에 먼지가 끼어 전류를 방해하거나 합선시키기도 합니다. 우선 USB 포트를 청소해주세요. 오래된 USB 케이블 교체   USB 케이블이 오래된 경우, 접촉면이 휘거나 벌어져 제대로 꽉 맞물리지 않거나, 싸구려라면 심할 경우 접히고 접히다 단선된 상태일 수도 있습니다. 오래된 USB 케이블은 교체해주세요. 메인보드의 USB 선 연결 상태 확인   메인보드를 보면, 파워가 연결되는 부분과 정 반대쪽(주로 맨 아래쪽)에 위와 같이 생긴 USB 커넥터가 연결돼 있을 겁니다. 못 찾겠으면, 본체 전면 패널쪽에서 이어져 오는 선중에 위와 같이 생긴걸 찾아보세요. 저걸 빼서 대충 후후 불고 다시 꽂아주시기 바랍니다. 항상 꽂혀 있는 것이라 정성스레 청소할 필욘 없어요. 단, 저 케이블 어딘가가 접혀있다면 꼭 펴주세요. USB 절전 모드 사용 안 함   위 영상을 보시고 똑같이 따라해주세요. 일부 파워 용량
자세한 내용 보기

MySQL 데이터 타입과 Java 데이터 타입 비교/매칭

  안녕하세요? 혼살입니다. 블로그에 정말 오랜만에 글을 씁니다. 일하고 겜하고 일하고 겜하고 집에 박혀서 매일 똑같은 일상을 보내다 보니 블로그에 글을 오랫동안 안 쓰고 있었네요. 대부분 근황은 유튜브 동영상으로 대체하다 보니 더욱 더 그랬던 것 같습니다.   하지만 이번엔 영상보다 글로 남기는 게 더 유익할 것 같아 간만에 글을 쓰게 되었습니다. 바로 MySQL Data Types & Java Data Types 매칭! 현재 진행중인 외주 작업 중 SET 타입을 Java에선 어떻게 처리하나 찾아보다가 잘 정리된 블로그 글 을 발견해 나중에 손쉽게 찾기 위해 제 블로그에도 씁니다. 위 링크에 들어가시면 테이블로 잘 정리돼 있으니 한 번 들어가 보시는것도 괜찮겠네요. 왼쪽은 MySQL, 오른쪽은 Java의 데이터 타입입니다. BIT <-> Boolean TINYINT <-> Integer BOOL/BOOLEAN (TINYINT(1)) <-> Integer SMALLINT <-> Unsigned 상관없이 Integer MEDIUMINT <-> Integer, Unsinged라면 Long INT <-> Integer, Unsigned라면 Long BIGINT <-> Long, Unsigned라면 java.math.BigInteger FLOAT <-> Float DOUBLE <-> Double DECIMAL <-> java.math.BigDecimal DATE <-> java.sql.Date DATETIME <-> java.sql.Timestamp TIMESTAMP <-> java.sql.Timestamp TIME <-> java.sql.Timestamp YEAR <-> yearsIsDateType이 설정됐다면 java.sql.Date, 아니라면 Short CHA
자세한 내용 보기