3장 JUnit 마스터하기

스텁 애플리케이션(stup application)

    - 특정 도메인의 일부 기능중 연동과 같은 상호작용 테스트에 필요한 기반만 별도로 애플리케이션을 작성한 것. 단위테스트를 수행하는 junit과는 개념이 다르다.

부트스트랩 테스트(bootstrap test)

    - 초기 테스트 환경 설정 기반 마련 및 테스트 수행을 일컫는다. 테스트를 위한 도구, 라이브러리 선택 및 테스트 대상 애플리케이션에 간단한 테스트 수행등 일련의 모든 과정이 이에 해당한다.

픽스처(Fixtures)는 테스트를 수행하기 위해 사전에 정의된 상태나 환경을 말한다. 

픽처스(Fixtures)는 테스트 픽스처의 여러 상태나 상황들을 가리키는 복수형이다. 테스트 수행에 필요한 여러 픽스처들을 포괄하는 개념이다.

@Before

    - 실제 테스트 대상이 되는 테스트 메서드가 실행되기 전 이 애노테이션이 붙은 메서드가 먼저 수행되며, 먼저 수행 된다는 성격만 보아도 주로 공통적으로 필요한 설정이나 초기화 작업을 수행하는데 쓴다.

@After

    - Before와 반대로 각각의 테스트 메서드가 실행 된 후에 수행되며 주로 테스트 이후 clean-up을 하는데 활용된다.

@BeforeClass

    - 테스트 클래스의 모든 테스트 메서드들이 실행되기전 이 애노테이션이 붙은 메서드가 먼저 딱 한번 실행되며 클래스 수준으로 초기화 작업을 수행하는데 주로 사용된다.

@AfterClass

    - BeforeClass와 마찬가지로 딱 한번 실행되며, 클래스 단위로 정리작업을 수행하는데 쓰인다. 

위 4가지 애노테이션의 공통점

    - public이어야 하고, Class 애노테이션이 붙은 메서드는 반드시 static여야 한다.

    - 원할경우 한번에 여러개의 메서드를 정의 할 수 있지만 이들 사이의 실행 순서를 정하는 방법은 없다. (4.6기준)

    - 성격을 보면 알 수 있듯, 테스트 이전 이후의 공통코드나 값들에 대해 세팅을 하기 위해 최적이다.

 

구현이 덜 끝난 테스트코드는 예외를 던져야한다. 

테스트 메서드에는 의미있는 이름을 부여하라. assert와 같은 특정 테스트 메서드만으론 목적을 정확히 전달하기에 부족한 경우가 종종 있다. 필요하다면 주석을 추가하는 것도 좋다.

- assert를 사용할땐 항상 첫 파라메터로 String을 받는 습관을 가지자. 이로써 실패 원인을 기술하게 되므로 assert 실패시 테스트 러너가 테스터에게 의미 있는 설명을 제공 할 것이다. (ex : assertNotNull("Must not return a null response", response); )

단위테스트

단위테스트의 핵심은 한번에 한 객체씩 테스트하는데 있다. 자바와 같은 객체지향 환경의 객체는 기본적으로 다른 객체와 상호작용하도록 설계되는데, 단위 테스트를 작성하려면 두 가지 종류의 객체가 필요하다. 테스트 대상이 되는 도메인 객체와 대상 객체와 상호작용할 테스트 객체(Mock Object 같은 테스트에 필요한 객체)이다. 단위 테스트에서의 도메인 객체는 실제 애플리케이션 범주에 포함 된 객체를 말한다. 단위테스트는 다른 메서드 들과의 API 계약을 잘 지키고 있음을 보장하는데 도움을 준다. 만약 메서드가 어떤 방식이든 파라미터나 필드의 값을 수정한다면 테스트가 필요한 고유 기능이 존재한다는 의미이다. 이러한 메서드는 향후 코드를 수정하면 오동작 할 가능성이 있는 기능을 가지므로 수정시에 테스트도 함께 추가해야한다.

@Test 메서드에는 하나의 테스트만 수행하자. 스스로를 더 잘게 나눌 수 없다면 나누기엔 너무 단순한 것이며 이는 미리 기능을 추가하지 말라는 익스트림 프로그래밍 규칙과도 일맥상통한다. 여러 테스트를 하나의 메서드에 넣게 되면 어느 부분에서 발생 된 문제인지 추적이 어려워지고 worst는 테스트를 테스트하는 테스트코드를 작성하는 상황이 오게 된다. 테스트 도 결국은 자바코드임을 잊지말고, 단일 책임 원칙을 잊지말자. 테스트 메서드 안에서 assert 문을 전혀 사용하지 않는 것도 테스트 코드 작성이 미흡한 사람에겐 흔한 실수 일 수 있다. 항상 모든 테스트에는 assert를 사용하여 테스트 결과를 확인 할 수 있도록 하자. assert가 없다면 그 테스트 코드는 무조건 성공으로 표시한다. assert를 사용하지 않아도 좋은 유일한 경우는 exception을 던져 알릴 때 뿐이다.

테스트를 통해 코드를 개선하라

단위 테스트 작성은 더 좋은 코드 작성에 도움이 된다. 왜냐, 당연하게도 우리가 작성한 코드를 사용하기 때문이다. 코드를 사용하기 전까진 그 단점들이 눈에 보이지 않는다. 코드를 작성하면서 눈에 보인다면 부득이한 경우가 아니라면 당연히 수정할테니까. 테스트 도중 불편한 점이 보인다면, 더 사용하기 쉬운 코드로 리팩터링을 하자. 테스트 주도 개발 (Test Driven Development, TDD) 가 이 원칙을 기반으로 하고 있다.