E2E 테스트를 향한 개인적인 소감

왜 E2E 테스트를 작성해야 하는가?

1. 서비스의 특성

---

제가 담당하고 있는 측면 감시 서비스는 대게 각 서비스의 기능 간 의존성이 굉장히 강한 서비스입니다.

A가 선행되지 않으면 B를 테스트할 수 없는 구조로 이루어져 있습니다.

회원가입같은 외부 디펜던시 없이 실행할 수 있는 기능들은 unit 테스트로도 충분히 그 기능의 실행을 보장할 수 있지만 만약, 특정 구성원의 거래내역을 확인하고 싶다면

• 관리자 회원가입 ⇒ 관리자가 개인 회원을 초대함 ⇒ 초대된 개인 회원이 초대를 승인함 ⇒ 초대된 회원이 구성원으로 들어감 ⇒ 구성원이 시험을 생성함 ⇒ 생성된 시험을 취소함 ⇒ 관리자가 구성원의 거래내역을 확인

같은 시나리오가 모두 존재해야 기능을 테스트할 수 있다고 칠 때 개인적으로 unit 테스트의 개별 단위로 쪼개서 테스트 하는 것은 큰 의미가 없다고 생각 했습니다. 결국 시나리오 상 위 과정이 모두 포함되야 하는데, 하나라도 빠져 있다면 실제 서비스에서 작동하지 않을 것이고 그렇다면 테스트를 하는 의미가 없기 때문입니다.

이러한 의존성이 강한 서비스의 각 기능들을 테스트하기 위해서는 통합 테스트나 E2E 테스트를 진행하는 것이 좋다고 생각했습니다.이 과정에서, 통합테스트를 진행하기 보다는 포스트맨으로 직접 API를 부르는 과정을 E2E 테스트로 축약할 수 있다고 생각 했습니다.

처음 E2E 테스트를 작성할 때에는, DynamoDB를 Maria Db로 마이그레이션하는 과정에서 실제 정상 작동하는지 테스트 하기위한 이유로 실제 DB와 연결된 데이터를 사용하고 싶어 작성했습니다. 그 이후로는 특정 메서드 단위의 실행 동작은 정상 작동했지만, 서비스 단위에서 작동하지 않을 수 있다는 것을 깨달았고 그 이후는 서비스에서 작동하지 않을 수 있는 환경이 있다고 느꼈고 핸들러 단위의 E2E 테스트를 진행하게 됐습니다.

기존의 E2E 테스트는 사실 통합테스트에 가까운 테스트 였지만, 지금은 실제 E2E 테스트라고 느껴지는 테스트를 진행 중입니다.

하지만, 이 과정에서 몇 가지 어려움을 겪게 됐습니다.

2. 각 E2E 테스트 간 독립적인 테스트 환경 보장

---

시나리오는 틀리지 않았습니다. 하지만, 각 E2E 테스트간 실행 환경의 독립성이 보장되지 못해

병렬적으로 실행되는 E2E 테스트간 데이터의 간섭이 일어나 테스트 케이스가 실패하게 됐습니다.

이를 해결하기 위해, 각 테스트를 직렬화해 동기적으로 실행시키는 방안을 생각해 봤지만 이것은 근본적인 해결책이 되지 못하며 또 테스트 실행의 속도가 느려지기 때문에 결과적으로 비생산적이라고 느꼈습니다.

3. 문제의 원인

---

그렇다면 문제에 대한 원인은

1. 개발계 DB 환경을 그대로 테스트에 사용기존 Beta 버전의 테스트 데이터가 남아 있는 개발 환경에서 작업을 진행하기 때문에 누군가 개발 서버에서 작업을 하다보면 올바른 시나리오의 테스트가 죽을 수도 있기 때문입니다.
2. 현재 테스트를 진행중인 DB는 개발을 위한 개발 서버의 데이터베이스로, 같은 개발 서버의 TEST 용 데이터베이스를 만들고 이를 활용하여 작성해야 한다는 점이었습니다.
3. 각 테스트 환경별로 중복되는 유저 셋업이 과정에서 각 E2E 테스트 파일간 충돌이 일어나게 됐습니다.이 기능이 실행되던 중 다른 테스트에서 구성원이 시험을 생성하고 있다면 각 E2E 파일 내부에서는 독립적으로 환경이 유지되지만 파일간에는 그렇지 않기 때문에 제 예상과는 다르게 테스트 케이스가 실패할 수 있는 것 입니다.
4. 그렇기 때문에 각 E2E 테스트 파일 별로 다른 계정을 사용해야 했단든 것을 깨닫게 됐습니다.
5. 일례로 병렬적으로 실행되는 E2E 테스트 중, 구성원의 시험생성 개수를 확인하는 기능이 있는데
6. 위에서 설명한대로 서비스의 기능간 의존성이 심화되다보니, 테스트를 작성할 때도 위 의존적인 상황들을 고려하여 이미 그런 환경이 구축된 계정을 사용하려고 했습니다.
7. 중복된 코드
8. 데이터를 셋업하고 지우고 하는 과정은 통합되고 축약될 수 있다는 것을 알게 됐습니다.
9. 외부 요인
10. 테스트 과정에서 외부 요인들 때문에 고생을 겪었습니다. 통제하기 어렵고 테스트 하기 어려운 AWS의 기능들이나 그 외 서드파티 도구들이 통제되기 어렵다고 느꼈습니다.

4. 결론

---

결론적으로 E2E 테스트 중 지켜야 할 사항들을 정했습니다.

1. 각 테스트별로 최대한의 의존성 제거
2. 모든 E2E 테스트 파일들은 최대한 독립적으로 실행되야 합니다. 각 테스트별 실행이 다른 테스트에 영향을 주지 않도록 명확히 작성되야 합니다.
3. 서드파티나 그 외 외부 도구들은 최대한 지양마찬가지로 AWS의 PreSignedUrl을 발급하는 것 또한, FE에서 눈에 보이는 이미지를 확인할 필요가 없으며 외부 요인(PEM키 없음, 잘못된 KEY 사용)을 통제하는 것은 실질적으로 어렵다고 느꼈습니다.차라리 이런 외부 요인들만을 따로 모아 테스트를 진행하는 것이 실질적으로 더 의미 있지 않을까 그런 고민을 했습니다.
4. 결국 이런 외부 요소들이야 말로 개별적으로 실행되어 시나리오와 무관하게 실제 동작만이 중요하다고… 느꼈습니다.
5. 이러한 요인들은 테스트 외적으로 점검해야할 부분들이며, 테스트를 통해 이런 외부 요인들을 점검하고 관리할 시간을 만들어 내는 것이 더 유의미하다고 생각했습니다.
6. 이메일을 보낸다거나 SMS를 보낸다거나 하는 기능들은 최대한 지양하는 것이 좋다고 생각했습니다. 실제 유저에게 도착한 모습들은 서버에서 이것이 정상작동 한다고 확인하는 것이 테스트도 어려울 뿐더러, 이것을 테스트 하는 것은 직접 눈으로 확인하면서 테스트해야 하기 때문에 큰 의미가 없다고 생각했습니다.
7. 테스트 DB 사용
8. 위에서 서술한 대로 테스트를 위한 DB를 개설하는 것이 맞습니다.
9. 중복 제거 및 시작 환경 세팅
10. 각 테스트 별 시작 환경을 셋업해주는 클래스를 만들어 관리하는 것이 좋습니다. 그리고 중복되고 축약될 수 있는 코드는 리팩토링을 통해 정리하는 것이 좋습니다.