JUnit 기반 Java 테스트 코드 작성방법

JUnit은 자바 단위 테스트 자동화를 지원하는 프레임워크입니다. 단위 테스트를 왜 작성해야 하는지에 대한 내용은 아래 링크 참조 바랍니다. 이번 포스팅에서는 자바 단위 테스트 프레임워크인 JUnit을 활용하여 단위 테스트 코드를 작성하는 방법에 대해 알아보겠습니다.

 

단위 테스트 코드 작성의 필요성

JUnit으로 작성된 단위 테스트 코드 구조

JUnit으로 단위 테스트 코드를 작성할 때, 메서드를 어노테이션으로 테스트 코드로 작성할 수 있습니다. 메서드 상단에 작성된 @Test 어노테이션은 메서드를 단위 테스트로 지정 가능합니다. 그리고 메서드 안에 테스트할 내용을 작성합니다. 테스트 코드를 작성할 때, 일반적으로 3A구조로 작성합니다.

단위 테스트 작성원칙

JUnit 실행 구조

JUnit은 어노테이션이 지정된 메서드 또는 클래스를 실행합니다. JUnit은 @BeforeClass로 지정된 클래스를 가장 먼저 실행하고, 그 이후로는 @Test, @Befre, @After로 지정된 메서드를 실행합니다. 테스트 케이스가 모두 실행 완료되면 @AfterClass로 지정된 클래스가 실행됩니다. 아래 이미지를 참고하시면, JUnit의 실행 순서를 쉽게 이해하실 수 있습니다.

JUnit 실행 구조

JUnit에서 지원하는 어노테이션은 아래 표와 같이 제공합니다. Annotation은 테스트 메서드 또는 클래스의 행위를 지정하는 것입니다. Test Fixture는 테스트를 실행할 때, 객체들의 상태를 고정시키는 것입니다.

Annotation	지정 대상	설명
@After	메서드	@Before에서 설정한 테스트 픽스쳐를 제거하기 위해 사용됩니다
@AfterClass	메서드	@BeforeClass 에서 설정한 테스트 픽스쳐를 제거하기 위해 사용됩니다
@Before	메서드	테스트 픽스쳐를 만들기 위해 사용됩니다
@BeforeClass	메서드	생성에 맋은 시간이 소요되는 픽스쳐를 설치하는 용도로 사용됩니다
@Ignore	메서드	해당 테스트 케이스를 실행하지 않도록 합니다
@RunWith	테스트 할 클래스	테스트 케이스를 실행할 테스트 러너를 지정할 수 있습니다
@Suite	테스트 할 클래스	단위 테스트 케이스들을 묶어서 같이 실행하고 싶을 때 사용합니다
@Test	메서드	테스트 케이스로 지정합니다

테스트 케이스에서 기대 출력 값과 실제 출력 값을 비교하는 구문은 Assert입니다. 출력 값에 해당하는 변수의 타입의 종류가 다양하므로, JUnit에서 다양한 변숫값을 비교할 수 있도록 여러 종류의 Assert구문을 지원하고 있습니다.

메서드	설명
assertEquals(expected,actual)	두 객체의 equals 결과가 참인지 검사한다
assertTrue(actual)	계산결과가 참인지 검사한다
assertFalse(actual)	계산결과가 거짓인지 검사한다
assertNotNull(actual)	계산결과가 null이 아닌지 검사한다
assertNull(actual)	계산결과가 null인지 검사한다
assertSame(expected,actual)	두 객체가 동일 객체인지 검사한다
assertNotSame(expected,actual)	두 객체가 동일 객체가 아닌지 검사한다
fail("Test Fail")	테스트 케이스를 실패시킨다
assertArrayEquals(expected,actual)	두 개의 배열의 equals 값이 참인지 검사한다

JUnit 실행결과

JUnit 테스트 코드의 실행 결괏값은 Pass, Fail 그리고 Error 상태 값을 가집니다. 통과(Pass)는 Assert문이 통과되었을 때 가지는 상태 값입니다. 실패(Fail)는 Assert문이 실패 한경우입니다. 그리고 오류(Error)는 테스트 케이스 실행 시 예외가 발생하여 오류가 발생한 경우입니다.

언제 단위 테스트 코드를 수정해야 하는가?

테스트 코드는 요구사항을 구체화한 산출물이라고 볼 수 있습니다. 요구사항을 테스트 코드로 먼저 정의한 뒤 기능을 개발하는 방법론을 TDD(=Test-Driven Developemnt)라고 합니다. 테스트 코드도 소스코드이므로, 의도를 불분명하게 작성하거나, 반복적으로 동일한 테스트 코드를 작성하면 비효율이 발생합니다. 그러므로, 테스트 코드도 지속적으로 유지보수를 수행해주어야 합니다. 테스트 코드를 검증할 때, 코드 스멜, 행동 스멜 또는 프로젝트 스멜이 발견된다면, 테스트 코드는 수정되어야 합니다.

분류	스멜	설명
코드스멜	테스트하기 어려운 코드	코드를 테스트 하기 어렵다
	모호한 테스트	테스트의 의도를 이해하기 쉽지 않다
	테스트 코드 중복	동일한 테스트 코드가 반복 된다
	제품 코드에 포함된 테스트 로직	테스트 동안에만 사용되는 로직이 제품 코드에 포함되어 있다
	조건 테스트 로직	테스트에 실행될 수 도 있고, 실행되지 않을 수도 있는 로직이 포함되어 있다
행동 스멜	Assertion Roulette	테스트 내에 여러가지 Assertion이 있어서 어떤 테스트 때문에 실패했는지 확인하기 어렵다
	변덕스러운 테스트	동작이 언제 되는지 알 수 없다
	깨지기 쉬운 테스트	테스트 하는 단위가 아닌 곳이 수정되어도 테스트가 실패한다
	느린 테스트	테스트 실행에 시간이 오래 소요된다
프로젝트 스멜	버그가 많은 테스트	자동화된 테스트에서 버그가 많이 발견된다
	버그가 많은 제품	제품을 공식적으로 테스트할 때 많은 버그가 발견된다
	테스트 코드 유지보수 비용	기존 테스트 코드를 유지보수하는데 많은 비용이 발생한다
	테스트 코드를 작성하지 않는 개발자들	개발자들이 자동화된 테스트를 작성하지 않는다