1. 인수 테스트 리팩토링
중복 검증
위 사진의 시나리오에 따라 인수테스트를 작성할 때 지하철 노선이 삭제가 되었는지 검증하는 부분은 2가지 방법이 존재한다.
1. 삭제의 응답 코드로 확인
2. 지하철 노선 조회 요청 후 응답 값에서 확인
만약 2번처럼 지하철 노선 조회 요청 후 응답 값에서 확인을 한다면 위의 사진처럼 테스트 목적은 다르지만 같은 로직을 검증하는 인수 테스트가 발생할 수 있다.
물론 인수 테스트의 중복을 허용하지 않는 것은 아니지만 조금 더 효율적인 방법은 없을까?
인수 테스트 통합
인수 테스트 통합의 예시로 위의 사진처럼 CRUD를 하나의 테스트에서 검증하는 것이 있다.
하나의 테스트가 많은 것을 검증하는 것이 아닌가?
1, 2주차 미션에서 인수테스트를 작성하면서 API 레벨의 테스트만 작성하다 보니 인수테스트 = API 요청에 대한 테스트 이렇게 생각을 할 수 있다. 이 관점에서 봤을 때 인수테스트 통합은 다양한 API 요청에 대해서 한번에 테스트를 하고 있으므로 너무 많은 것을 검증하는 것이 아닌가 생각할 수 있다.
하지만 인수테스트는 API 테스트가 아니다.
인수테스트는 요구사항에 대한 검증을 하는 테스트이다. 따라서 사용자 관점의 기능과 플로우 또한 검증대상이 될 수 있다는 것이다. 이 개념은 Journey Test 또는 Story Test라는 개념으로 존재한다.
많은 것을 검증한다는 단점을 가지고 있지만...
분명 단점이 존재하지만 장점도 존재한다. 장점에 대해 알아보자.
-
인수 테스트 스텝의 중복을 효과적으로 제거함으로써 테스트 비용이 절감된다.
-
흐름을 검증하면서 자연스럽게 사용자 스토리에 대한 검증이 가능하다.
-
사이드 케이스는 단위 테스트에서 수행하게 유도한다.
이러한 장점이 존재하므로 간단한 요구사항이나 팀끼리 모두 어느정도 알고있는 요구사항에 대해서는 인수테스트 통합을 고려해볼 수 있다.
어떻게 인수테스트를 통합할 것인가?
-
기존처럼 따로 만든 다음 하나로 통합하기
-
처음부터 하나의 테스트 메소드로 한 스텝씩 검증하면서 구현하기
2. 레거시 리팩토링
기존 레거시에 인수테스트가 있는 경우
이 경우는 정말 좋은 케이스이다. 왜냐하면 기능 변경 혹은 리팩토링을 하더라도 인수테스트가 있기에 마음껏 할 수 있기 때문이다. 또한 작업하다가 막히거나 꼬이더라도 인수 테스트가 성공하는 시점으로 돌아갈 수 있다.
기존 레거시에 인수테스트가 없는 경우
이 경우가 문제인데 인수 테스트를 먼저 만들고 시작한다.
세부 구현에 의존하지 않는 블랙박스 테스트이기 때문에 구현이 변경되더라도 검증이 가능하다.
인수테스트 작성 후 다음스텝
기존 코드를 바로 수정하면 어떻게 될까?
변경한 부분을 의존하는 부분에서 모두 빨간불이...... 😱😱😱😱😱
또 기존 테스트 코드가 모두 실패하는 참사가?!?! 😱😱😱😱😱
1. 새로운 테스트 만들기
반드시 기존 테스트와 프로덕션 코드는 그대로 두고 새로운 테스트를 만든다!!
2. 기능 구현하기
-
기존 코드와 중복이 발생할 수 있다.
-
기존 코드와 신규 코드가 함께 존재한다.
-
작업 중 다른 작업을 하더라도 문제가 없다.
-> 기존 코드가 유지되어 기능에 이슈는 없고, 신규 작업한 코드도 그대로 남아있기 때문 -
단, 기존 코드와 신규 코드가 혼재되는 기간을 짧게 가져가도록 해야한다.
3. 테스트 성공 후 리팩토링
리팩토링은 테스트 코드가 검증할 수 있는 범위 내에서 시도한다.
4. 1번 ~ 3번 반복
기존 코드를 대체할 수 있을 때 기존 프로덕션 코드와 테스트 코드를 제거한다.
참고
만약 order 메소드에 대해 변경을 하고자 한다면 order 메소드의 코드를 바로 수정하는 것이 아니라 order2 메소드를 만든 뒤 새로운 테스트 코드와 함께 TDD를 하라는 것이다. 따라서 여기서 기존 코드와 중복이 발생할 수 있다는 것이다.
또한 TDD가 끝났다면 즉 대체할 수 있다면 기존의 order 메소드를 제거하고 order2 메소드를 order로 바꾸라는 것이다.
