E2E 테스트, 더 견고하고 이해하기 쉽게 만드는 방법
E2E 테스트는 UI의 현재 상태(신호)가 아닌, 시스템이 보장해야 할 '약속'에 집중해야 함을 강조
테스트 코드의 가독성을 높이고, UI 변경에 유연하게 대처할 수 있는 방법 제시
Playwright를 활용한 테스트 코드 예시를 통해, 실제 적용 방법을 설명
커뮤니티에서는 기존 테스트 프레임워크와의 비교를 통해, 실질적인 가치에 대한 논의가 진행됨
신호(Signals)와 약속(Promises)의 불일치
본문에서는 E2E 테스트가 UI의 구체적인 신호(Signals), 즉 가시성, 텍스트 내용, 활성화 상태 등을 검증하는 대신, 테스트가 실제로 보장하려는 약속(Promises)에 집중해야 한다고 주장한다. 이는 테스트의 무결성(Integrity)을 높이고, UI 변경에 따른 테스트 실패를 줄이는 데 기여한다. 특히, UI 표현이 변경되어도 테스트는 동일한 약속을 유지해야 한다고 강조한다.
테스트 코드의 가독성 및 유지보수성 향상
저자는 테스트 코드의 가독성을 높이기 위해, UI의 세부 사항을 직접 검증하는 대신, 도메인 용어(Domain Terms)를 사용하여 테스트를 작성할 것을 제안한다. 예를 들어, '성공 배지'의 가시성을 확인하는 대신, '임포트 완료' 상태를 확인하는 방식으로 테스트 코드를 작성한다. 이러한 접근 방식은 테스트의 의미를 명확하게 전달하고, 코드 중복(Code Duplication)을 줄이는 데 도움이 된다.
Playwright 기반의 테스트 코드 예시
저자는 Playwright를 사용하여, 신호 기반 테스트와 약속 기반 테스트의 차이점을 보여주는 구체적인 예시를 제시한다. 신호 기반 테스트는 UI 요소의 가시성, 텍스트 내용, 활성화 상태 등을 직접 검증하는 반면, 약속 기반 테스트는 '임포트 완료', '실패 항목 수', '오류 보고서 사용 가능 여부'와 같은 도메인 용어를 사용하여 테스트한다. 구체적인 구현 코드는 본문에 포함되지 않았다.
테스트 프레임워크와 추상화의 역할
댓글에서는 저자가 제시한 방법론이 기존 테스트 프레임워크의 추상화(Abstraction)와 유사하다는 의견이 제시된다. 특히, 숙련된 엔지니어는 raw Playwright 스크립트를 직접 작성하기보다는, 커스텀 DSL(Domain Specific Language)을 사용하여 테스트 프레임워크를 구축하는 경향이 있다. 따라서, 저자가 제시한 방법론이 실제 프로젝트에 얼마나 가치(Value)를 제공하는지에 대한 논의가 이루어진다.
