문서요약 - JUnit과 CPPUnit에 의한 단위 테스팅 by Pietroszek

제목: JUnit과 CPPUnit에 의한 단위 테스팅(Unit testing with JUnit and CPPUnit)

저자: Krzysztof Pietroszek, 워털루 대학, 캐나다

문서유형: 학계 발표 자료

 

단위 테스팅 프레임워크(JUnit, CPPUnit)를 활용한 단위 테스팅에 대하여 간단히 소개한 자료

---

구식의 저레벨 테스팅 방법

• 디버거를 단계별로 밟아 가는 방식: 자동이 아니며 시간이 많이 소요됨
• 코드 여기저기에 출력 스트림 호출을 심어 놓는 방식: 코드를 난잡하게 만들고 너무 많은 정보를 생성

단위 테스팅 3-단계 솔루션

①    각 코드 단위(시스템의 작은 조각, 예를 들면 클래스)를 위한 테스트 집합을 생성

②    테스트를 테스트 스위트(test suite)로 구성

③    소스 코드 변경이 있은 후에(그리고 체크인을 하기 전에) 자동화된 테스트를 실행

단위 테스팅의 장점

• 테스트를 작성함으로써 무엇을 해야 하는지에 대해 더 잘 이해 할 수 있게 됨
• 단순 실수로 인한 버그들이 즉시 드러남. 디버깅에 쏟는 시간을 줄여줌
• 코드 기능에 대한 실질적인 명세를 제공함
• 개발 속도를 가속화: 한번 작성한 테스트를 여러 차례 에러 발견에 사용
• 자신의 코드에 대한 확신(confidence)을 얻음
• 반복가능하고(Repeatable) 결정론적(deterministic)
• 회귀 테스트(Regression tests): 부정확한 변경이 즉시 발견됨, 비자동 리팩토링(unautomated refactoring)이 가능해짐

JUnit와 CPPUnit의 역사

• JUnit 테스팅 프레임워크는 eXtreeme Programming style의 모범 관행 중 하나를 위한 도구 지원으로써 개발됨. Kent Beck과 Erich Gamma가 개발
• JUnit은 이후 C++를 위한 CPPUnit으로 재탄생 됨

JUnit/CPPUnit 테스트 작성 시 워크플로우(테스트-주도 개발)

①    구현되어야 할 기능성/시나리오(테스트 할 단위가 어떤 역할을 수행)에 대해 생각해 본다.

②    구현하고자 하는 단위의 스터브를 생성한다.

③    각 시나리오(또는 단위의 사용)를 위한 테스트를 작성한다.

④    단위가 테스트에 실패하도록 만든다(아직은 구현된 것이 전혀 없음).

⑤    모든 테스트를 통과할 때까지 단위를 개발한다.

새로운 시나리오/사용법에 마주치게 되면? 구현 전에 테스트를 작성한다!

예 1 - TestCase

①    TestCase의 서브클래스로써 테스트 클래스를 생성하고, 테스트 되는 클래스명에 접미사 “Test”를 붙여서 이 테스트 클래스를 명명한다.

②    테스트 되는 메쏘드명에 접두사 “test”를 붙여서 테스트 메쏘드를 명명한다.

③    테스트 통과 조건을 주기 위해 assertTrue(), assertEquals(), assertFalse() 등을 사용한다. 예) assertTrue(x == 10);

④    Test fixture(유사한 테스트들의 집합을 실행하기 위한 공통 환경)를 구축한다. 이 환경을 구축하고 해제하기 위해 setUp()과 tearDown() 메쏘드를 사용한다.

예 2 - TestSuite

• TestSuite 클래스의 서브클래스를 생성함으로써 테스트를 테스트 스위트로 구성한다.
• 테스트 케이스를 추가하기 위해 add 메쏘드를 사용하거나 또는 JUnit/CPPUnit이 테스트 케이스로부터 테스트를 추출하도록 한다.
• Test runner를 사용하여 테스트를 실행한다.
  – java junit.awtui.TestRunner (과거 AWT UI)
  – java junit.swingui.TestRunner (새로운 Swing UI)
  – java junit.textui.TestRunner (텍스트 UI)
  – CppUnit::TextUi::TestRunner (CPPUnit 텍스트 UI)

자주 묻는 질문(FAQ)

Q: “테스트 작성하는 것이 많은 양의 일처럼 보이는데”

A: 네, 하지만 에러 발생 전에 테스트를 작성하는 편이 그 후에 작성하는 것보다 훨씬 쉽고 효율적임이 증명되었습니다.

 

Q: “아직 구현되지 않은 클래스 B에 의존하는 클래스 A를 테스트 하고 싶은데?”

A: 가짜 클래스 B를 생성하여 그 메쏘드들이 기대하는 값들만 리턴하도록 만드세요.

 

Q: “내 클래스가 너무 크고 너무 많은 시나리오에서 사용되는지라 어디부터 시작해야 할지 모르겠는데”

A: 그건 모듈성(modularity)이 나쁘다는 것을 나타냅니다. 클래스를 잘 정의된 작은 조각들로 분할하고 이것들을 개별적으로 테스트 하세요.

 

Q: “어디다가 제 테스트를 집어넣어야 할까요?”

A: 동일 패키지(package.MyClass, package.MyClassTest)에 넣거나 또는 별도 패키지(package.MyClass, packageTest.MyClassTest)에 넣으세요.

 

Q: “UI는 어떻게 테스트 하나요?”

A: 각 UI 시나리오가 일련의 이벤트들입니다. 이 이벤트들을 생성하는 가짜 UI 클래스를 만드세요(도구 지원 없이는 어려움).

 

Q: “프로세스 간의 커뮤니케이션은 어떻게 테스트 하나요?”

A: 그건 단위 테스트 보다는 시스템 테스트 또는 통합 테스트에서 다뤄집니다.