1. Overview

TDD, BDD, ATDD를 공부하고 있다. 그 전에 사전 배경지식으로 단위테스트와 통합테스트, 인수테스트를 정리하고 가고자 한다. 그 전에 우리가 테스트하고자하는 모듈이란 무엇인지 먼저 알아보자.

2. 모듈이란

모듈화란 소프트웨어를 각 기능 별로 나누는 것을 의미한다. 이러한 모듈화의 결과를 모듈이라고 한다.
프로그램에서 모듈은 프로그램의 구성요소로, 관련된 데이터와 함수를 하나로 묶은 단위라고 할 수 있다. 모듈은 교체 가능하게끔 설계해야하며 우리는 이러한 모듈들을 조합하여 프로그램을 만든다.

결합도와 응집도의 차이

이러한 모듈의 독립성을 판단하는 지표가 결합도와 응집도이다.

결합도는 서로 다른 모듈 간의 상호 의존 정도를 의미하며 응집도는 한 모듈 내부의 처리 요소들이 서로 관련되어있는 정도를 의미한다.

3. 단위테스트란

단위 테스트란 프로그램에서 테스트 가능한 가장 작은 소프트웨어를 실행하여 예상대로 동작하는지 확인하는 테스트를 의미한다.

즉 특정한 책임을 수행하면서, 고립될 수 있는 최소 단위를 테스트하는 것으로, 보통 모듈 내 하나하나의 메서드를 고립될 수 있는 최소 단위로 보고 테스트하기 위해 단위테스트 코드를 작성한다.

프로그래밍을 하다보면 모듈 내에서 다른 모듈을 의존하여 메서드를 호출한다. 이럴 경우 mocking처리한다.

사용하는 도구(자바)

• Junit5
• Mockito
• reactor-test
• AssertJ
  reactor를 단위테스트

hamcrest는 사용 지양하자! 레거시이다.

사용하는 도구(스프링)

• @WebMvcTest
Controller를 단위테스트하기 위해 지원하는 어노테이션으로 Present Layer 관련 컴포넌트만 스캔하여 빈으로 등록한다.
• MockMVC
  실제 tomcat을 구동하지 않고 mocking하여 테스트하는 것을 지원한다.
• @DataJpaTest
  JPA관련하여 레포지토리를 테스트할 때 주로 사용하며 관련된 빈을 스캔해 등록한다. 또한 기본적으로 @Transactional이 붙어 있으며 임베디드 데이터베이스를 사용하여 외부 디비 없이도 단위테스트를 짤 수 있다.

4. 통합테스트란

통합테스트란 여러 모듈들이 모여 이들이 의도대로 협력하는지 확인하는 테스트를 의미한다.

단위테스트 코드를 작성할 땐 외부 모듈에 의존성이 있을 경우 이를 mocking 처리하였다. 통합테스트 시에는 이러한 외부 모듈도 mocking하지 않고 실제로 의존성을 주입하여 테스트한다고 생각하면 된다.

즉 하나의 모듈에 대해 단위테스트, 통합테스트 코드 모두 작성할 수 있다. 예를들어 해당 모듈의 순수 비즈니스 로직이 잘 동작하는지 테스트하기 위해 단위테스트를, 다른 모듈들과의 협력 과정에서도 비즈니스 로직이 제대로 동작하는지 테스트하기 위해 통합테스트 코드 모두 작성하는 것이다.

@SpringBootTest

통합테스트 == @SpringBootTest가 아니다!
통합테스트코드 작성 시에는 해당 모듈을 테스트하기 위해 필요한 객체만 생성하고 주입하여 테스트해야한다. @SpringBootTest는 모든 빈을 올려 통합테스트하고자할 때 사용한다. 모든 빈을 올려 테스트해야하는 경우가 아니라면 가능한 필요한 의존성만 주입하여 통합테스트를 작성하자.

사용하는 도구(스프링)

• @DataJpaTest
  기본적으로는 임베디드 데이터베이스를 사용하지만 AutoConfigureTestDatabase 옵션을 수정하여 실제 @ActiveProfiles로 활성화하여 외부 디비와 통신하여 통합테스트 코드를 작성할 수 있다.
• @SpringBatchTest

5. 인수테스트란

먼저 인수(acceptance)는 무슨 뜻일까

인수테스트는 소프트웨어 인수를 목적으로 하는 테스트이다. 사용자 입장에서 요구사항을 만족하였는지를 검증하는 것을 목적으로 한다.

백엔드에서 인수테스트란 소프트웨어 인수를 목적으로 사용자 스토리(시나리오)에 맞춰 수행하는 테스트이다.

그래서 인수테스트는 개발자보다는 시나리오에 따른 비즈니스 쪽에 초점을 둔다. 프로젝트에 참여하는 사람들(ex. 기획자, 클라이언트 대표, 개발자 등)이 토의해서 시나리오를 만들고, 개발자는 이에 의거해서 코드를 작성한다. 그래서 테스트 구조가 어떤지, 어떤 컴포넌트가 포함되는지 등 기술적인 관점과 전혀 상관없이 클라이언트가 기대하는 동작에 대한 검증이 중요하다.

고객이 기대하는 백엔드에서의 시나리오 동작은 무엇일까, API이다. 그래서 주로 API에 인수테스트 코드를 작성한다.

사용하는 도구

MockMVC로도 가능하지만 보통 RestAssured 사용한다.

RestAssured는 실제 web environment인 Apache Tomcat 활용하는데
MockMVC는 mocking 된 web environment 환경에서 테스트한다는 차이가 있다.

통합테스트 vs 인수테스트

인수테스트도 결국 통합테스트라고 볼 수 있다.

하지만 통합테스트와 인수테스트는 목적의 차이가 있다고 할 수 있다.
통합테스트는 개발자 관점에서 기능에 결함이 없고 제대로 동작하도록 구현하였는지 검증한다. “a = 2, b = 3이라면 a + b 는 5이다.”

인수테스트는 사용자 관점에서 요구사항에 따라 시스템이 제대로 동작하는지 검증(요구사항 스토리를 base로 한다.)
“사용자는 상품을 구매한다.”