테스트 범위와 종류

기능 테스트

기능 테스트는 사용자 입장에서 시스템이 제공하는 기능이 올바르게 동작하는지 확인한다.

이는 QA들이 하는 테스트와 동일한 것으로 보인다. 이 테스트의 전제조건은 매우 크다.

 

그림 기준으로 나열하자면

 

1. 정상적으로 동작하는 프런트엔드 코드가 필요하다.

2. 인프라가 정상적으로 구동된 상태여야 한다.

3. 데이터베이스도 연동되어야 한다.

4. 실제 클라이언트 환경도 필요하다.

5. 실제 클라이언트와 벡엔드 코드가 합쳐져 빌드되어서 웹 애플리케이션 서버를 구동시켜야 한다.

 

이렇게 기능 테스트는 사용자의 환경부터 시작해서 데이터베이스나 외부 서비스를 이용한다면 해당 외부 API 서버까지 모든 구성 요소를 하나로 엮어서 진행한다. 

 

이는 끝에서 끝까지 올바른지 검사하기 때문에 End to end라고도 볼 수 있다.

 

통합 테스트

 

Integration Testing은 시스템의 각 구성 요소가 올바르게 연동되었는지 확인하는 테스트이다.

기능 테스트가 사용자 입장에서 바라본 테스트라면 통합 테스트는 소프트웨어 코드를 직접 테스트한다. 

 

일반적으로 웹 애플리케이션은 프레임워크, 라이브러리, 데이터베이스, 구현한 코드가 주요 통합 테스트 대상이다. 

 

이러한 테스트로는 프레임워크 설정이 올바른지, 데이터베이스 연동이 잘되었는지, SQL이 올바른지, 데드락은 없는지 트랜잭션이 잘 동작하는지를 검증할 수 있다.

 

단위 테스트

 

단위 테스트 Unit Testing이라고 하는데, 이는 개별 코드나 컴포넌트가 기대한 대로 동작하는지 확인한다. 

보통 TDD를 구현할 때 작성되는 테스트가 단위 테스트이다. 이는 한 클래스나 한 메서드와 같은 작은 범위를 테스트한다. 

이 과정에서 의존성이 필요하다면 스텁이나 모의 객체 등을 이용해서 대역으로 대체한다. 

 

최근 테스트를 미친 듯이 작성하는 것도 전부 단위 테스트이다. 

 

단위 테스트가 실행시간도 짧고 외부 리소스에 영향을 받지 않아서 더 많이 빠르게 테스트할 수 있다는 장점이 있다.

하지만 결국 대역을 사용하는 한계가 존재한다. 각 구성 요소가 올바르게 연동되는 것을 확인해야 하는데 이를 자동하기 좋은 수단이 테스트 코드이다. 

 

테스트 범위에 따른 테스트 코드 개수와 시간

 

 

요즘은 전 범위의 테스트를 자동하여 배포하는 소프트웨어가 참 많다. 이는 테스트를 자동화하는 만큼 고품질의 소프트웨어를 더 빠르게 출시할 수 있기 때문이다. 

하지만 테스트 자동화라고 해서 코드를 자동으로 작성해주는 것은 아니고 코드로 작성된 테스트를 실행한다는 것을 말한다.

 

기능 테스트를 수행하려면 A-Z까지 모든 환경이 갖춰져야 하기에 자동화하거나 다양한 상황별로 테스트하기 가장 어렵다.

따라서 정기적으로 수행하는 기능 테스트는 정상적인 경우와 몇 가지 특수한 상황만 테스트 범위로 잡는다.

 

통합 테스트는 기능 테스트에 비해 제약이 덜하다. 기능 테스트에 비해 상대적으로 실행 시간이 짧고 상황을 보다 유연하게 구성할 수 있기 때문에 기능 테스트보다는 통합 테스트를 더 많이 작성한다. 

 

스프링을 사용한다면 @WebMvcTest와 같이 컨트롤러와 연관된 부분만 빈으로 올려 테스트할 수 있고 이에 더불어 Mockito까지 사용한다면 service와 같은 레이어도 모의 객체로 쉽게 대역이 가능하다.

 

단위 테스트는 정말 통합 테스트로 만들기 힘든 상황을 아주 쉽게 구성할 수 있다. 더 작은 단위를 대상으로 테스트 코드를 작성하기 때문에 거의 모든 상황에 대해 테스트 코드를 작성할 수 있기 때문이다. 

 

이때 중요한 내용이 있다. 테스트를 작성하다 보면 중복되는 테스트가 종류별로 생기기 마련이다. 

이러한 경우에는 테스트 속도가 단위 테스트가 가장 빠르기 때문에 단위 테스트에서 다양한 종류의 테스트를 다루고 통합 테스트나 기능 테스트는 정말 중요한 비즈니스 흐름에 초점을 맞춰 선별하여 테스트를 선정하는 걸 추천한다고 한다.