효과적인 프론트엔드 테스트에 대하여

오랜만에 인터뷰를 진행했습니다. 이 고통스러운 과정에서 눈에 띄는 것은 아예 테스트 문제가 제기되면 면접은 망한다는 점이다. 그 이유는 내 경험이 주로 프런트엔드 개발에 있었고 내가 머물렀던 두 회사는 프런트엔드 테스트가 매우 형편없었기 때문입니다.

--- 바로 토론으로 넘어가고 싶다면 건너뛰세요 ---

나의 부족함은 어떤 의미에서는 산업 문화의 부산물이었습니다. 프론트엔드 테스트는 항상 중요했지만, 10년 전만 해도 회사 구조에서는 테스트 문제와 개발 프로세스를 분리해 왔습니다. 그래서 우리는 개발자를 위해 E2E/자동 테스트를 작성하는 전담 QA 팀을 보유했습니다. 그래서 테스트는 직무 설명에도 없었습니다. 또한 소규모 스타트업의 불행한 진실은 항상 배송이 최우선이기 때문에 테스트가 생산성을 저해하기 때문에 우리 개발자들은 테스트를 하지 않았습니다. 저장소에는 테스트 라이브러리(Jasmine/Mocha/PhantomJS...)도 설치되어 있지 않았습니다.

저는 훨씬 더 큰 회사에서 두 번째 직업을 얻었습니다(소비자 플랫폼 팀에는 개발자가 150명 정도 있었나요?). 그러나 본질적으로 말하자면 테스트는 없었습니다. 각 팀(체크아웃, 충성도, 등록 등의 기능으로 구분된 팀)에는 E2E 테스트를 작성할 전담 QA 구성원이 있었습니다. 일단 문화가 확립되고 예산에서 QA가 삭감되면, 배울 사람이 없기 때문에 아무도 이를 선택하지 않았습니다. 우리 팀을 위해 몇 가지 E2E 테스트를 시도했지만 남겨진 코드는 작동하지도 않았고 명백한 버그(많은 WTF)로 가득 차 있었습니다. 또 다시 촉박한 마감 기한과 함께 테스트가 뒤쳐졌습니다. 사람들이 테스트에 대해 이야기한 유일한 시간은 유틸리티 기능과 사용자 정의 반응 후크에 관한 것이었습니다.

--- 토론 시작 ---

시험을 치르지 않는 문화 때문에 추상적으로 시험을 치르는 것에 대해 인터뷰할 때 최소한 할 수 있는 말은 해야 합니다. 스타일이나 구현을 테스트하지 않는다는 일반적인 헛소리는 건너뛰겠습니다.

토론에 자유롭게 추가하세요. 이것은 나의 과거 동료 중 적어도 300명에게 영향을 미칩니다!

1.) 전역 상태 테스트:
내 경험에 따르면 가장 형편없는 기능 중 하나는 "이런 일이 발생하면 자동으로 이 작업을 수행합니다" 유형의 동작입니다. 예를 들어, 제가 가지고 있던 앱 중 하나는 구성이 매우 자유로운 그래프 시각화 대시보드였습니다. 하나의 구성 변경으로 인해 반환된 데이터와 그렇지 않은 데이터에 따라 다른 구성도 변경될 수 있습니다. 일부 구성 부작용은 간단하지 않습니다. 따라서 자동 구성 변경 사항과 상태가 전반적으로 지속/변경되지 않음/일관되는지 여부를 테스트하고 싶을 것입니다. 따라서 이러한 유형의 동작을 테스트하는 경우 PM, 관리자, 디자인 및 QA 팀과 협력하는 것이 매우 중요합니다.

2.) UI 입력의 무결성을 테스트하는 데 많은 시간을 소비하지 마세요.
검색 창에 "taylor Swift"를 입력하고 Enter 키를 누르면 검색 기능이 taylor Swift를 입력으로 가져오는 것과 같이 입력 테스트에 대해 설명하는 튜토리얼이 꽤 많이 있습니다.

정말 도움이 되지 않습니다. 데이터 바인딩이 손상된 경우 개발 중에 직접 발견했어야 한다는 것이 매우 명백하거나 사용자가 검색어를 입력할 수 없도록 검색 창 위에 보이지 않는 div와 같은 기능을 방해하고 있기 때문에 자동으로 테스트할 수 없습니다.

코드 라인으로 지급을 받고 있다면 계속 진행하세요 :)

3.) 입력의 부작용으로 입력을 테스트하는 것이 바람직하지만:
2번과 달리 사용자 상호 작용에 완전히 부작용이 되는 기능 호출을 테스트하고 싶을 것입니다. 예를 들어, 사용자가 버튼을 클릭하면 데이터 분석을 위해 이 사용자 작업을 등록하라는 요청이 호출되어야 합니다. 핵심 기능과 완전히 분리된 이러한 유형의 부작용은 의도하지 않은 변경으로 인해 당황하지 않도록 자동으로 테스트되어야 합니다. 비핵심 부작용은 다른 팀에 필수적일 수 있는데, 저는 그런 팀 중 하나에 속해 있었습니다 :D

그렇다면 이러한 테스트 요구 사항을 어떻게 설계합니까?
프런트엔드 아키텍처를 분석해 보겠습니다. MVC(MVVM이라고 말할 수도 있고 그렇지 않다고 말할 수도 있지만 실제로는 중요하지 않습니다).

V - 보기(html/jsx): 이는 E2E/헤더리스 브라우저 테스트에 적합하며 업계 표준입니다.

C - 컨트롤러(비즈니스 로직): 기능이 올바른지 확인하는 데 시간을 투자하세요. 예를 들어, 순수 함수로 추상화한 경우 예상되는 입출력 프로세스가 여전히 그대로 유지됩니까? 다소 업계 표준이지만 사람들은 일반적으로 상태 저장 기능을 순수 기능으로 만들고 테스트하는 데 신경을 쓰지 않습니다.

M - 모델(API 호출/상태): 제가 가장 강조하고 싶은 부분입니다. (렌더링되지 않는) 상태는 전역이어야 하며 컨셉별로 싱글톤이어야 합니다. Redux가 기본적으로 그것이기 때문에 새로운 아이디어는 아닙니다. 그러나 테스트 목적으로 Flux일 필요는 없습니다. jotai Atom을 가질 수 있지만 테스트를 위해 중앙 집중식 설정 기능을 노출할 수 있도록 래퍼를 코딩할 수 있습니다.

API 호출/타사 라이브러리에서도 비슷한 작업을 수행해야 합니다. "이 작업을 수행할 때 애플리케이션에서 수행된 코어/비코어 API 호출"을 자신있게 테스트할 수 있도록 전역 및 싱글톤이어야 합니다. 이것은 나의 제한된 경험인 백엔드 애플리케이션에서 일상적으로 수행됩니다. 이는 프런트엔드 애플리케이션에서도 수행되어야 합니다.

이게 어떻게 들리나요? 이미 누군가가 이 작업을 수행하고 있다고 확신합니다. 귀하의 경험은 어떻습니까? 무엇이 개선될 수 있나요? 프런트엔드 테스트가 E2E/헤드리스 브라우저를 뛰어넘어 두뇌 없는 간단한 단위 테스트를 수행하는 사람들의 의견을 듣고 싶습니다.

위 내용은 효과적인 프론트엔드 테스트에 대하여의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!