[ATDD] 인수테스트 리팩터링

 

이번 시간에는 인수 테스트의 리팩터링 과정에 대하여 학습하였다.

 

1. 인수테스트 리팩터링

인수테스트에서 Command성 쿼리들을 StatusCode만으로 검증할 수 있을까?

실제로 데이터가 저장되었는지 확인해야 할까?

 

예를 들어 다음과 같은 지하철 삭제 시나리오가 있다고 해보자.

Scenario: 지하철 노선을 제거한다.
  Given 지하철 노선이 등록되어 있다
  When 지하철 노선을 삭제 요청한다.
  Then 지하철 노선이 삭제된다.

 

이 시나리오를 확인하는 방식은 다음과 같을 것이다.

• given: 지하철 노선 등록 request 보내기
• when: 지하철 노선 삭제 request 보내기
• then: 지하철 노선 삭제를 확인하기
  • 방법 1: 지하철 노선 삭제의 응답 코드로 확인
  • 방법 2: 지하철 노선 조회 request 후 response 값에서 확인

 

마지막 Then절의 검증 부분에서 사제 확인을 응답 코드로만 확인할 수도 있지만, 방법2와 같이 다시 조회 쿼리를 날려 확인할 수도 있다.

 

방법2는 given/when/then 이후 when/then의 스탭이 추가로 필요하다.

테스트 목적은 다르지만 같은 로직을 검증하는 인수 테스트가 의도하지 않게 발생할 수 있다.

 

예를 들어 다음 2가지 시나리오를 살펴보자.

하나는 노선 생성, 다른 하나는 노선 목록 조회이다.

  Scenario: 지하철 노선을 생성한다.
    When 지하철 노선을 생성 요청
    Then 지하철 노선이 생성됨
    When 지하철 노선 목록을 요청
    Then 지하철 노선 목록에서 확인됨

  Scenario: 지하철 노선 목록을 조회한다.
    Given 지하철 노선을 생성 되어있음
    When 지하철 노선 목록을 요청
    Then 지하철 노선 목록에서 확인됨

 

중복 검증 인가?

 

중복 검증이다! 사실상 같은 테스트를 중복해서 하고 있는 것이다.

물론 인수테스트에서 중복 검증을 허용하지 않는 것은 아니지만, 조금 더 효율적인 방법이 없을까?

 

2. 인수 테스트 통합하기

다음과 같이 하나의 인수테스트 에서 CRUD에 해당되는 큰 시나리오 하나를 전부 검증하는 것이다.

Feature: 즐겨찾기를 관리한다.

  Background 
    Given 지하철역 등록되어 있음
    And 지하철 노선 등록되어 있음
    And 지하철 노선에 지하철역 등록되어 있음
    And 회원 등록되어 있음
    And 로그인 되어있음

  Scenario: 즐겨찾기를 관리
    When 즐겨찾기 생성을 요청
    Then 즐겨찾기 생성됨
    When 즐겨찾기 목록 조회 요청
    Then 즐겨찾기 목록 조회됨
    When 즐겨찾기 삭제 요청
    Then 즐겨찾기 삭제됨

 

2-1) 하나의 테스트가 많은 것을 검증하는 것이 아닌가?

인수테스트는 API 테스트가 아니다.

인수테스트는 요구사항에 대한 검증을 하는 테스트이다. 따라서 사용자 관점의 기능과 플로우 또한 검증대상이 될 수 있다는 것이다.

이 개념은 Journey Test 또는 Story Test라는 개념으로 존재한다.

 

https://martinfowler.com/bliki/UserJourneyTest.html

bliki: UserJourneyTest

 

2-2) 통합 시 장점

1. 테스트 비용 절감
2. 인수 테스트 스텝의 중복을 효과적으로 제거할 수 있음
3. 흐름을 검증하면서 자연스럽게 사용자 스토리에 대한 검증이 가능
4. 사이드 케이스는 단위 테스트에서 수행하게 유도

인수테스트를 통합할때는, 기존처럼 단건의 인수테스트를 모두 만든 후 합쳐도 되고, 한 번에 커다란 스토리를 만들어도 된다!