테스트란, 테스트의 대상을 검증하는 것을 말한다. 그렇다면 테스팅 코드는 왜 작성해야 할까? 그냥 포스트맨으로 테스트해도 되지 않나?

매번 포스트맨을 이용하여 요청과 응답을 보내다보면 세상 귀찮아진다...또한, 애플리케이션의 코드들은 API-Business-Data Access 계층이 서로 얽혀 있기 때문에 계층 별로 나누어 테스트 하기에는 포스트맨이 적합하지 않다.

따라서 별도의 테스팅 코드를 작성하는 이유는 계층 별로 테스트를 진행하고, 비효율적인 포스트맨의 사용을 줄이기 위함이다.

단위 테스트(Unit Test)

하나의 메서드 단위로 진행되는 테스트

F.I.R.S.T. 원칙

최대한 이 원칙을 따르면서 작성하도록 연습하는 것이 필요하다!

Fast(빠르게)

테스트 케이스를 자주 돌려 결과를 얻어야 하기 때문에 빨라야 한다.

Independent(독립적으로)

테스트 케이스의 실행 순서는 보장되어 있지 않기 때문에 서로의 결과에 영향을 미치지 않도록 해야 한다.

Repeatable(반복 가능하도록)

어떤 환경에서든 반복적으로 실행이 가능해야 한다. 외부 서비스나 외부 리소스가 연동되는 경우에는 동일한 테스트 결과를 가져오기 어렵기 때문에 테스트 시에는 외부 연동을 끊어주는 것이 바람직

Self-validating(셀프 검증이 되도록)

성공 혹은 실패라는 자체 검증 결과가 있어야 한다.

Timely(시기 적절하게)

TDD에 맞게 기능 구현 전 테스트 케이스를 작성해야 한다.

💡TDD(Test Driven Development) 테스트 주도 개발
: 기능 구현 전, 실패할 테스트 케이스를 먼저 작성하고 순차적으로 기능 구현과, 테스트 케이스가 통과하도록 개발하는 방법

given-when-then

가독성 높은 테스트 케이스를 작성하기 위해 BDD(Behavior Driven Development: 행동 주도 개발)의 given-when-then 테스트 방식을 사용한다.

given : 테스트에 given(주어진) 값

테스트의 필요한 전제 조건(전달되는 입력값 등)을 말한다.

when : 테스트를 When(언제) 진행하는지

테스트를 진행할 동작(대상)

then : then(그 다음엔?)

예상하는 값(expected)과 테스트의 결과값(actual)을 검증하는 영역

JUnit

Java 언어로 만들어진 애플리케이션을 테스트하기 위한 Java의 표준 테스트 프레임워크

JUnit의 기본 구조

Assertion

예상하는 결과값이 참이길 바라는 것, 검증!

JUnit에는 Assertion할 수 있는 다양한 메서드들이 존재한다.

assertEquals(a, b)

a와 b가 같으면 성공!

assertThrows(Exception.class, ()-> 람다식)

람다식의 테스트 메서드가 호출되면 발생하는 예외를 테스트

Hamcrest

Junit 기반의 단위 테스트에서 사용할 수 있는 Assertion 프레임워크

• Assertion을 위한 Matcher가 자연스러운 문장으로 이어져 가독성 향상
  • JUnit : assertEquals(expected, actual)
  • Hamcrest : assertThat(actual, is(equalTo(expected)))
• 테스트 실패 메세지도 가독성이 좋다.
• 다양한 Matcher 제공