• 바로가기

1. 단위테스트의 기초

1.1 단위 테스트를 작성하는 이유

• 테스트 시간 단축으로 문제점 발견 가능성이 높아지고 안정성 향상
  • 단위 테스트의 목적은 프로그램의 각 부분을 고립시켜서 각 부분이 정확하게 동작하는지 확인하게 합니다
  • 문제 발생 시 정확히 어느 부분이 잘못되었는지 확인할 수 있습니다
  • 디버깅 시간을 단축시킴으로써 시간을 오히려 단축시킵니다
• 이전 기능도 함께 테스트하기 때문에 더 쉬워진 코드 변경
  • 프로그래머는 단위 테스트를 믿고 리팩토링을 합니다
  • 리팩토링 후에도 해당 모듈이 의도대로 작동하고 있음을 단위 테스트를 통해 확신할 수 있는데, 이를 회귀 테스트라고 합니다
• 테스트 간 결합도가 낮으므로 간단해진 통합
  • 단위 테스트는 상향식 테스트 방식에서 유용합니다
  • 단위를 합쳐서 다시 검증하는 통합 테스트에서는 더욱 빛을 발합니다

1.2 JUnit 테스트 좀 더 이해

• fail 정적 메소드는 org.junit.Assert 클래스에 있습니다
• @Test 어노테이션은 org.junit 패키지에 있습니다
• 테스트 클래스 이름은 타겟 클래스 이름에 Test를 붙여서 만들어줍니다
• JUnit은 @Test 어노테이션이 붙은 test 메소드를 테스트로 실행합니다. 테스트 클래스에는 테스트 메소드가 아닌 메소드도 포함될 수 있으며 JUnit이 알아서 제외합니다

1.3 테스트 준비, 실행, 단언

• JUnit4의 assertThat은 JUnit5의 assertEquals와 같습니다
• 테스트의 단언문은 테스트의 마지막에 넣습니다
• 테스트 주도 개발을 따르는 프로그래머들은 테스트에서 일부러 실패합니다

1.4 @Before 메소드로 테스트 초기화하기

• JUnit 테스트를 실행할 때마다 @Before 어노테이션으로 표시된 메소드를 먼저 실행합니다
• 초기화 로직을 여기다 적으면 코드의 가독성을 높일 수 있습니다

1.5 JUnit의 작동순서

1. JUnit은 새로운 Test Class의 인스턴스를 만듭니다
2. @Before 메소드에 따라 필드를 초기화합니다
3. 메소드를 실행합니다
4. 다른 테스트가 있다면 1번을 반복합니다

이렇듯 JUnit은 모든 테스트를 독립적으로 만듭니다(테스트끼리의 결합성을 낮춥니다). 그렇지 않다면 테스트의 실패 이유를 찾는것이 너무 어려워지기 때문입니다. 따라서 테스트 클래스에서는 static 필드를 사용하지 않습니다

2. JUnit 단언 깊게 파기

2.1 JUnit 단언

JUnit에서 단언은 테스트에 넣을 수 있는 정적 메소드 호출입니다. 각 단언은 어떤 조건이 참인지 검증하는 방법입니다. 단언한 조건이 참이 아니면 테스트는 즉시 종료하고 실패를 보고합니다(또한 JUnit은 catch하지 않은 exception에 대해서 error로 말합니다)

2.1.1 assertTrue

assertTrue는 true냐 false냐에 대해 단언합니다. 하지만 테스트코드는 검증하는 기댓값을 명시적으로 지정하는 것이 낫습니다

@Test
public void depositIncreaseBalance(){
	//account는 @Before을 통해 초기화 필요
	int initialBalance = account.getBalance();
	account.deposit(100);
	assertTrue(account.getBalance() > initialBalance);
}

2.1.2 asserThat

대부분 단언은 기대하는 값과 반환된 실제 값을 비교합니다. 단지 잔고가 0보다 크다고 하기보다는 100과 같은지를 비교합니다

@Test
public void depositIncreaseBalance(){
	//account는 @Before을 통해 초기화 필요
	int initialBalance = account.getBalance();
	account.deposit(100);
	assertThat(account.getBalance(), equalTo(100));
}

assertThat() 정적 메소드는 햄크레스트 단언의 예입니다. 햄크레스트 단언의 첫 번째 인자는 실제 표현식, 즉 우리가 검증하고자 하는 값입니다. 두 번째 인자는 매처입니다. 매처는 실제 값과 표현식의 결과를 비교합니다.

또한 assertThat은 fail 시 expected : <100> but : was <101>와 같은식으로 쓸모있는 에러메시지를 반환합니다. 하지만 assertTrue는 fail 메시지만 반환할 뿐이므로 추가적인 디버깅이 필요합니다

assertThat(account.getName(), is(notNullValue()));
. . .

위의 코드에서 name이 null을 반환한다면 아래의 코드는 동작하지 않습니다. 이때, 예외를 던지는 null 참조 예외는 텍스트 오류가 발생하며 테스트 실패는 발생하지 않습니다.

2.2.1 AAA로 테스트 일관성 유지

• 준비(Arrange) : 테스트 코드를 실행하기 전에 시스템이 적절한 상태에 있는지 확인합니다. 객체들을 생성하거나 다른 API를 호출하는 등이 포함됩니다.
• 실행(Act) : 테스트 코드를 실행합니다. 보통 단일 메소드를 호출합니다
• 단언(Assert) : 실행한 코드가 기대한 대로 동작하는지 확인합니다. 실행한 코드의 반환값 혹은 그 외 필요한 객체들의 새로운 상태를 검사합니다

추가적으로 때에 따라 4번째 단계가 필요할 수도 있습니다

• 사후(After) : 테스트를 실행할 때 어떤 자원을 할당했다면 잘 정리 되었는지 확인합니다

2.2.2 동작 테스트 VS 메소드 테스트

테스트를 작성할 때는 클래스 동작에 집중해야 하며 개별 메소드를 테스트한다고 생각하면 안됩니다

예를 들어, 은행의 ATM 클래스를 생각해봅시다. 클래스의 메소드에는 deposit(), withdraw(), getBalance()가 있습니다

makeSingleDeposit, makeMultipleDepoist 테스트가 있다고 할 때, 각 테스트 결과를 검증하려면 getBalance() 메소드를 호출해야합니다. 하지만 getBalance()를 테스트 하는게 의미가 있을까요? getBalance()는 단지 객체의 필드를 반환하기만 하는 메소드이기 때문입니다. 테스트 대상이 될만한 동작에는 입금과 출금 같은 다른 동작이 나와야 합니다. 예를 들면 makeSingleWithdrawl, makeMultipleWithdrawls, attemptToWithdrawTooMuch 등과 같이 말이죠.

단위 테스트를 작성할 때는 먼저 전체적인 시각에서 시작해야 합니다. 개별 메소드를 테스트하는 것이 아니라 클래스의 종합적인 동작을 테스트해야 합니다

2.2.3 테스트와 프로덕션 코드의 관계

테스트는 주어진 프로젝트 안에서 프로덕션 코드와 분리해야 합니다. 테스트는 프로그래머만 하는 활동이고, 고객이나 사용자는 프로덕션 코드를 실행하기만 합니다.

따라서 테스트 코드는 프로덕션 시스템 코드에 의존하지만, 반대는 아닌 일방향 관계입니다.

대부분 소프트웨어를 배포할 때 테스트를 제외한 채 베포합니다. 왜냐하면 테스트를 포함할 경우 JAR 파일이 부풀려지고(성능 저하), 코드 베이스의 공격 표면도 늘어나기 때문입니다.

2.2.4 테스트 코드 이름짓기

단위 테스트는 문서의 역할을 해야 합니다. 따라서 테스트의 이름에 더 많은 의미를 부여할 수 있습니다. 테스트하려는 맥락을 제안하기보다는 일련의 행동을 호출했을 때 어떤 결과가 나오는지를 명시해야 합니다

양식은 doingSomeOperationGenerateSomeResult(어떤 동작을 하면 어떤 결과가 나온다)

또는 someResultOccursUnderSomeCondtion(어떤 결과는 어떤 조건에서 발생한다)

혹은 BDD의 given-when-then 양식을 따라 givenSomeContextWhenDoingSomeBehaviorThenSomeResultsOccurs(주어진 조건에서 어떤 일을 하면 어떤 결과가 나온다)

여기서 givenSomeContext를 제외하여 whenDoingSomeBehaviorThenSomeResultOccurs(어떤 일을 하면 어떤 결과가 나온다) 등으로 표현합니다