자동화 된 프론트 엔드 테스트는 훌륭합니다. 코드가있는 테스트를 작성하여 페이지를 방문하거나 단일 구성 요소 만로드 할 수 있으며 테스트 코드가 사용자와 같이 사물을 클릭하거나 텍스트를 입력 한 다음 상호 작용 후 응용 프로그램 상태에 대한 주장을합니다. 이를 통해 테스트에 설명 된 모든 것이 응용 프로그램에서 예상대로 작동하는지 확인할 수 있습니다.
이 게시물은 자동화 된 UI 테스트의 빌딩 블록 중 하나이므로 사전 지식이 너무 많지 않습니다. 기본에 이미 익숙하다면 첫 두 섹션을 건너 뛰십시오.
테스트를 작성할 때 아는 데 유용한 고전적인 패턴이 있습니다 : 예약 , 행동 , 주장 . 프론트 엔드 테스트에서는 다음을 수행하는 테스트 파일로 변환됩니다.
상호 작용할 내용을 지정한 다음 나중에 페이지 에서 확인 해야하는 내용을 사용하여 다양한 요소 로케이터를 사용하여 사용해야 할 DOM의 일부를 타겟팅 할 수 있습니다.
로케이터는 요소의 ID, 요소의 텍스트 내용 또는 .Blog-post 또는 article> div.container> div> p : nth-Child (12)와 같은 CSS 선택기와 같은 것일 수 있습니다. 테스트 러너에게 해당 요소를 식별 할 수있는 요소에 대한 모든 것은 로케이터가 될 수 있습니다. 마지막 CSS 선택기에서 이미 알 수 있듯이 로케이터는 많은 품종으로 나옵니다.
우리는 종종 부서지기 쉬우 거나 안정적이라는 측면에서 로케이터를 평가합니다. 일반적으로 요소 주변의 코드가 시간이 지남에 따라 변경 되더라도 테스트가 항상 필요한 요소를 찾을 수 있도록 가장 안정적인 요소 로케이터를 원합니다. 즉, 모든 비용에서 안정성을 극대화하면 실제로 테스트를 약화시키는 방어 테스트 작성으로 이어질 수 있습니다. 우리는 테스트가 원하는 것과 일치하는 Brittleness와 안정성을 조합하여 가장 많은 가치를 얻습니다.
이런 식으로 요소 로케이터는 덕트 테이프와 같습니다. 그들은 한 방향으로 실제로 강해야하며 다른 방향으로 쉽게 찢어 야합니다. 우리의 테스트는 응용 프로그램에 중요하지 않은 변경이 이루어질 때 함께 유지하고 계속 통과해야하지만 테스트에 지정된 내용과 모순되는 중요한 변경이 발생하면 쉽게 실패해야합니다.
먼저, 실제 사람이 자신의 일을하도록 지시를 쓰고 있다고 가정 해 봅시다. 새로운 게이트 검사관이 Gate Inspectors, Inc에서 방금 고용되었습니다. 당신은 그들의 상사이며, 모든 사람이 소개 된 후에는 첫 번째 게이트를 검사하는 지침을 제공해야합니다. 그들이 성공하기를 원한다면 아마도 다음과 같은 메모를 작성 하지 않을 것입니다 .
노란 집을지나 가서 마이크의 어머니의 친구의 염소가 그 시간을 놓치는 들판을 쳤을 때까지 계속 가십시오. 그런 다음 왼쪽으로 돌리고 길 건너편의 집 앞의 문이 열리 든 아니든 말 해주세요.
이러한 지시는 긴 CSS 선택기 또는 XPath를 로케이터로 사용하는 것과 같습니다. 부서지기 쉬우 며“나쁜 종류의 취성”입니다. 옐로우 하우스가 다시 칠되고 계단을 반복하면 더 이상 게이트를 찾을 수 없으며 포기하기로 결정할 수 있습니다 (또는이 경우 테스트가 실패합니다).
마찬가지로, Mike의 어머니의 친구의 염소 상황에 대해 모른다면, 올바른 참조 지점에서 어떤 게이트를 확인 해야하는지 알 수 없습니다. 이것이 바로“나쁜 종류의 취성”을 나쁘게 만드는 이유입니다. 테스트는 모든 종류의 이유로 깨질 수 있으며, 그 이유 중 어느 것도 게이트의 유용성과 관련이 없습니다.
따라서 훨씬 더 안정적 인 다른 프론트 엔드 테스트를하겠습니다. 결국,이 지역에서 합법적으로, 주어진 도로의 모든 문은 제작자로부터 고유 한 일련 번호를 가져야합니다.
일련 번호 1234가있는 게이트로 이동하여 열리는 지 확인하십시오.
이것은 ID로 요소를 찾는 것과 비슷합니다. 더 안정적이고 한 단계 일뿐입니다. 마지막 테스트에서 실패의 모든 실패 지점이 제거되었습니다. 이 테스트는 해당 ID가있는 게이트가 예상대로 열리지 않는 경우에만 실패합니다.
이제 두 개의 게이트가 같은 도로에 동일한 ID를 가져서는 안되지만 실제로는 실제로 시행되지는 않지만 어느 날 도로의 다른 게이트는 같은 ID로 끝납니다.
그래서 다음에 새로 고용 된 게이트 검사관이“게이트 1234”를 테스트 할 때, 그들은 다른 것을 먼저 발견하고 이제 잘못된 집을 방문하여 잘못된 것을 확인하고 있습니다. 테스트가 실패하거나 악화 될 수 있습니다. 해당 게이트가 예상대로 작동하면 테스트는 여전히 통과하지만 의도 한 주제를 테스트하지는 않습니다. 그것은 거짓 자신감을 제공합니다. 한밤중에 원래 대상 게이트가 도난당한 경우에도 계속 지나갈 것입니다.
이와 같은 사건 이후, ID는 우리가 생각했던 것만 큼 안정적이지 않다는 것이 분명합니다. 따라서 우리는 차세대 사고를하고 게이트 내부에서 테스트를위한 특별한 ID를 원한다고 결정합니다. 이 게이트에만 특별 ID를 넣기 위해 기술을 보내 드리겠습니다. 새로운 테스트 지침은 다음과 같습니다.
테스트 ID“My-Favorite-Gate”가있는 게이트로 가서 열리는 지 확인하십시오.
이것은 인기있는 data-testid 속성을 사용하는 것과 같습니다. 이와 같은 속성은 코드에서 자동화 된 테스트에서 사용하기위한 것이며 변경 또는 제거해서는 안된다는 것이 분명하기 때문에 훌륭합니다. 게이트에 그 속성이있는 한 항상 게이트를 찾을 수 있습니다. ID와 마찬가지로 독창성은 여전히 시행되지 않지만 조금 더 가능성이 높습니다.
이것은 당신이 얻을 수있는만큼 부서지기 쉬우 며 게이트의 기능을 확인합니다. 우리는 테스트를 위해 의도적으로 추가 한 속성을 제외하고는 아무것도 의존하지 않습니다. 그러나 여기에 숨어있는 약간의 문제가 있습니다…
이것은 게이트의 사용자 인터페이스 테스트이지만 로케이터는 사용자가 게이트를 찾는 데 사용하지 않을 것입니다.
이 가상 카운티에서는 사람들이 주소를 볼 수 있도록 집 번호를 인쇄 해야하는 것으로 밝혀 졌기 때문에 기회가 놓쳤습니다. 따라서 모든 문에는 독특한 인간을 향한 레이블이 있어야하며 그렇지 않으면 그 자체로 문제가됩니다.
테스트 ID로 게이트를 찾을 때 게이트가 다시 칠되고 집 번호가 커버 된 것으로 밝혀지면 테스트가 여전히 통과됩니다. 그러나 문의 요점은 사람들이 집에 접근하는 것입니다. 다시 말해, 사용자가 찾을 수없는 작업 게이트는 여전히 테스트 실패 여야하며,이 문제를 드러낼 수있는 로케이터를 원합니다.
다음은 첫날 게이트 검사관에 대한이 테스트 명령의 또 다른 패스입니다.
집 번호 40을 위해 게이트로 가서 열리는 지 확인하십시오.
이것은 테스트에 값을 추가하는 로케이터를 사용합니다. 사용자가 의존하는 것에 따라 달라집니다. 이는 게이트의 레이블입니다. 그것은 실제로 테스트하고자하는 상호 작용에 도달하기 전에 테스트가 실패하는 잠재적 인 이유를 추가합니다. 이는 언뜻보기에 나쁘게 보일 수 있습니다. 그러나이 경우 로케이터는 사용자의 관점에서 의미가 있기 때문에 우리는 이것을“취성”으로 으 rug하지 않아야합니다. 레이블로 게이트를 찾을 수 없다면, 그것이 열리 든 아니든 상관 없습니다. 이것은“좋은 종류의 취성”입니다.
많은 프론트 엔드 테스트 조언은 DOM 구조에 의존하는 로케이터를 쓰지 않도록합니다. 즉, 개발자는 시간이 지남에 따라 구성 요소와 페이지를 리팩터링 할 수 있으며 테스트가 새로운 구조를 따라 잡기 위해 테스트를 업데이트하지 않고도 사용자를 대상으로 워크 플로가 깨지지 않았 음을 확인할 수 있습니다. 이 원칙은 유용하지만 프론트 엔드 테스트에서 관련없는 DOM 구조에 의존하는 로케이터를 쓰지 않아야한다고 말하면 약간 조정합니다.
응용 프로그램이 올바르게 작동하려면 DOM은 주어진 시간에 화면에있는 컨텐츠의 특성과 구조를 반영해야합니다. 이에 대한 한 가지 이유는 접근성입니다. 이러한 의미에서 올바른 DOM은 보조 기술이 올바르게 구문 분석하고 브라우저에서 렌더링 된 내용을 보지 않는 사용자에게 설명하기가 훨씬 쉽습니다. DOM 구조와 일반 구식 HTML은 보조 기술에 의존하는 사용자의 독립성에 큰 차이를 만듭니다.
프론트 엔드 테스트를 통해 앱의 연락처 형식에 무언가를 제출합시다. 우리는이를 위해 사이프러스를 사용하지만, 로케이터를 선택하는 원리는 전략적으로 요소를 찾는 데 DOM을 사용하는 모든 프론트 엔드 테스트 프레임 워크에 전략적으로 적용됩니다. 여기서 우리는 요소를 찾고, 일부 테스트를 입력하고, 양식을 제출하고,“감사합니다”상태에 도달했는지 확인합니다.
//? 권장되지 않습니다 cy.get ( '#name'). type ( 'mark') cy.get ( '#comment'). type ( '테스트 댓글') cy.get ( '. 제출 -Btn'). 클릭 () cy.get ( '. 감사합니다').
이 네 줄에는 모든 종류의 암시 적 주장이 있습니다. cy.get ()는 요소가 DOM에 존재하는지 확인하고 있습니다. 일정 시간이 지나면 요소가 존재하지 않으면 테스트가 실패하고, 유형과 같은 작업 및 클릭하면 요소가 표시되고 활성화되고 다른 것에 의해 방해받지 않는지 확인하십시오.
따라서 우리는 이와 같은 간단한 테스트에서도 많은 "무료"를 얻지 만, 우리 (그리고 사용자)가 실제로 신경 쓰지 않는 것에 대한 의존성도 소개했습니다. 우리가 확인하는 특정 ID와 클래스는 특히 Div.Main> P : nth-Child (3)> span.is-a-button 등과 같은 셀렉터에 비해 충분히 안정적으로 보입니다. 이 긴 선택기는 너무 구체적이므로 DOM에 대한 사소한 변경으로 인해 기능이 깨지기 때문에 요소를 찾을 수 없기 때문에 테스트가 실패 할 수 있습니다.
그러나 #Name과 같은 짧은 선택기조차도 세 가지 문제가 있습니다.
문제 1과 2의 경우 권장 솔루션은 종종 HTML에서 전용 데이터 속성을 사용하여 테스트를 위해 독점적으로 추가됩니다. 테스트는 더 이상 DOM 구조에 의존하지 않기 때문에 더 나은 것이 좋습니다. 개발자가 구성 요소 주변의 코드를 수정함에 따라 올바른 입력 요소에 첨부 된 데이터 테스트 = "이름 필드"를 유지하는 한 업데이트가 필요하지 않고도 테스트가 계속 전달됩니다.
이것은 문제를 해결하지 못합니다.
요소 로케이터는 로케이터에 대한 무언가가 사용자 경험에 중요하기 때문에 실제로 의존하고 싶은 것에 의존 할 때 의미가 있습니다. 대화식 요소의 경우, 사용하기에 가장 적합한 선택기는 요소의 접근 가능한 이름이라고 주장합니다. 이와 같은 것이 이상적입니다.
//? 추천 cy.getByLabelText ( 'name'). type ( 'mark')
이 예제는 Cypress Testing Library의 BylabelText 도우미를 사용합니다. (실제로, 어떤 형태로든 테스트 라이브러리를 사용하는 경우 이미 접근 가능한 로케이터를 작성하는 데 도움이 될 것입니다.)
이는 현재 내장 점검 (cy.type () 명령을 통해 무료로 얻는)에 양식 필드의 접근성이 포함되어 있기 때문에 유용합니다. 모든 대화식 요소에는 보조 기술에 노출되는 접근 가능한 이름이 있어야합니다. 예를 들어, 스크린 리더 사용자는 필요한 정보를 입력하기 위해 입력 한 양식 필드가 호출되는 방법입니다.
양식 필드 에이 액세스 가능한 이름을 제공하는 방법은 일반적으로 ID에 의해 필드와 관련된 레이블 요소를 통해 이루어집니다. Cypress Testing Library의 GetByLabelText 명령은 필드에 적절하게 레이블이 붙어 있음을 확인하지만 필드 자체는 레이블을 가질 수있는 요소임을 확인합니다. 예를 들어, 유형 () 명령이 시도되기 전에 다음 HTML이 올바르게 실패합니다. 레이블이 존재하더라도 div 라벨은 유효하지 않기 때문입니다.
<label for="my-custom-input"> 편집 가능한 div 요소 : </label> <div contenteditable="true"></div>
이것은 유효하지 않은 HTML이기 때문에 ScreenReader 소프트웨어는이 레이블을이 필드와 올바르게 연결할 수 없습니다. 이 문제를 해결하기 위해 실제 입력 요소를 사용하도록 마크 업을 업데이트합니다.
<label for="my-real-input"> 실제 입력 : </label>
이것은 굉장합니다. 이제 DOM에 대한 편집 후이 시점에서 테스트가 실패하면, 관련없는 구조가 요소 배열 방식과 관련이 없기 때문이 아니라, 우리의 편집은 프론트 엔드 테스트가 명시 적으로 관리하는 DOM의 일부를 깨뜨리기 위해 무언가를했기 때문에 실제로 사용자에게 중요합니다.
상호 관계가 아닌 요소의 경우, 우리는 사고 한도를 씌워야합니다. DOM이 전혀 중요하지 않은 경우 항상 우리에게 있어야 할 데이터 사이 또는 데이터 테스트 속성에 빠지기 전에 약간의 판단을 조금 사용합시다.
우리가 일반적인 로케이터에 담그기 전에, DOM의 상태는 웹 개발자로서 우리의 모든 것입니다 (적어도, 나는 그것이 생각합니다). 그리고 DOM은 페이지를 시각적으로 경험하지 않는 모든 사람을 위해 UX를 운전합니다. 따라서 많은 시간 동안 테스트 로케이터에 포함시킬 수있는 코드에 사용할 수 있거나 사용할 수있는 의미있는 요소가있을 수 있습니다.
그리고 그렇지 않다면. 응용 프로그램 코드는 Div 및 Span과 같은 일반 컨테이너이며 테스트를 추가하면서 응용 프로그램 코드를 먼저 고정하는 것을 고려해야합니다. 그렇지 않으면 테스트가 실제로 일반 컨테이너가 예상되고 원하는 것을 명시 할 위험이있어서 누군가가 해당 구성 요소를보다 접근하기 쉽도록 수정하기가 조금 더 어렵습니다.
이 주제는 조직에서 접근성이 어떻게 작동하는지에 대한 벌레 캔을 열어줍니다. 종종 아무도 그것에 대해 이야기하지 않고 회사의 관행의 일부가 아니라면, 우리는 프론트 엔드 개발자로서 접근성을 심각하게 받아들이지 않습니다. 그러나 하루가 끝날 무렵, 우리는 디자인을위한 "올바른 마크 업"이 무엇인지, 그리고 그것을 결정할 때 무엇을 고려해야하는지에 대한 전문가가되어야합니다. 나는 Connect.tech 2021의 이야기에서“접근 가능한 vue…
위에서 보았 듯이, 우리가 전통적으로 대화식으로 생각하는 요소들과 함께, 프론트 엔드 테스트에 쉽게 구축 할 수있는 아주 좋은 경험 법칙이 있습니다. 대화식 요소는 요소와 올바르게 관련된 레이블을 가져야합니다. 따라서 테스트 할 때 대화식이 필요한 라벨을 사용하여 DOM에서 선택해야합니다.
메인과 같은 일부 기본 랜드 마크를 제외하고 모든 텍스트를 표시하는 대부분의 콘텐츠 렌더링 요소와 같이 대화식으로 생각하지 않는 요소의 경우, 비 결과 컨텐츠를 일반적인 DIV 또는 스팬 컨테이너에 넣으면 등대 감사 실패를 유발하지 않습니다. 그러나 마크 업은 컨텐츠의 본질 과 구조를 볼 수없는 사람에게 설명하지 않기 때문에 기술을 보조하는 데 유익하거나 도움이되지 않습니다. (이것을 극단적으로 보려면 Manuel Matuzovic의 훌륭한 블로그 게시물 인“완벽한 등대 점수로 가능한 가장 접근 할 수없는 사이트를 구축하십시오.”)를 확인하십시오.)
우리가 렌더링하는 HTML은 중요한 맥락 정보를 시각적으로 인식하지 않는 사람에게 전달하는 곳입니다. HTML은 DOM을 구축하는 데 사용되며 DOM은 브라우저의 접근성 트리를 만드는 데 사용되며 접근성 트리는 모든 종류의 보조 기술이 소프트웨어를 사용하여 장애가있는 사람에게 가져갈 수있는 컨텐츠 및 작업을 표현하는 데 사용할 수있는 API입니다. ScreenReader는 종종 우리가 생각하는 첫 번째 예제이지만 접근성 트리는 웹 페이지를 점자로 바꾸는 디스플레이와 같은 다른 기술에서도 사용할 수 있습니다.
자동 접근성 점검은 콘텐츠에 대한 올바른 HTML을 실제로 만들었는지 알려주지 않습니다. HTML의 "권리"는 판단 호출을 통해 접근성 트리에서 어떤 정보를 전달 해야하는지에 대해 개발자를 만들고 있습니다.
우리가 그 전화를 한 후에는 자동화 된 프론트 엔드 테스트에 굽는 데 적합한 양을 결정할 수 있습니다.
ARIA 역할 상태가있는 컨테이너가 연락 양식에 대한“감사합니다”및 오류 메시징을 보유 할 것이라고 결정했다고 가정 해 봅시다. 이는 양식의 성공 또는 실패에 대한 피드백을 스크린 리더가 발표 할 수 있도록 좋을 수 있습니다. CSS 클래스.
이 요소를 추가하고 UI 테스트를 작성하려면 테스트가 양식을 작성하고 제출 한 후에 이와 같은 주장을 작성할 수 있습니다.
//? 권장되지 않습니다 cy.get ( '. 감사합니다').
또는 이와 같이 브리티틀이 아닌 의미없는 선택기를 사용하는 테스트조차도 다음과 같습니다.
//? 권장되지 않습니다 cy.get ( '[data-test]').
cy.contains ()를 사용하여 모두 다시 작성할 수 있습니다.
//? 추천 cy.contains ( '[role = "status"],'감사합니다, 우리는 귀하의 메시지를 받았습니다 ') .Should ( 'be.visible')
이것은 예상 텍스트가 나타나서 올바른 종류의 컨테이너 내부에 있음을 확인할 것입니다. 이전 테스트와 비교하여 실제 기능을 확인하는 측면에서 훨씬 더 가치가 있습니다. 이 테스트의 일부가 실패하면 메시지와 요소 선택기가 모두 우리에게 중요하고 사소하게 변경되지 않아야하기 때문에 알고 싶습니다.
우리는 여분의 추가 코드없이 여기에 약간의 적용 범위를 얻었지만 다른 종류의 Brittleness도 소개했습니다. 우리는 테스트에 평범한 영어 문자열을 가지고 있으며,“감사합니다”메시지가 "연락 해주셔서 감사합니다!" 이 테스트는 갑자기 실패합니다. 다른 모든 테스트와 동일합니다. 레이블 작성 방법에 대한 작은 변경은 해당 레이블을 사용하여 요소를 대상으로하는 테스트를 업데이트해야합니다.
우리는 코드에서와 마찬가지로 프론트 엔드 테스트에서 이러한 문자열에 대해 동일한 진실의 소스를 사용하여이를 향상시킬 수 있습니다. 그리고 현재 우리가 구성 요소의 HTML에 바로 인간이 읽을 수있는 문장이 포함되어 있다면 ... 이제 우리는 그 물건을 거기에서 뽑아 낼 이유가 있습니다.
마법의 숫자 (또는 덜 흥미롭게도, "이름이없는 수치 상수")는 좋은 오래된 1.023033 등과 같은 계산의 최종 결과에 중요한 코드에서 때때로 볼 수있는 초 특이 적 값입니다. 그러나 그 숫자는 표지되지 않기 때문에 그 중요성은 불분명하므로 그것이 무엇을하고 있는지 불분명합니다. 어쩌면 세금을 적용 할 수 있습니다. 어쩌면 그것은 우리가 모르는 버그를 보상 할 수 있습니다. 누가 알아?
어느 쪽이든, 프론트 엔드 테스트도 마찬가지이며 일반적인 조언은 명확성이 부족하여 마법의 숫자를 피하는 것입니다. 코드 리뷰는 종종 그것들을 잡아서 번호가 무엇인지 묻습니다. 상수로 옮길 수 있습니까? 값이 여러 곳에서 재사용 되려면 똑같은 일을합니다. 모든 곳에서 값을 반복하지 않고 변수에 저장하고 필요에 따라 변수를 사용할 수 있습니다.
수년에 걸쳐 사용자 인터페이스를 작성하면 HTML 또는 템플릿 파일의 텍스트 내용을 다른 컨텍스트의 마법 숫자와 매우 유사하게 보게되었습니다. 우리는 코드를 통해 절대적인 값을 전달하지만 실제로는 해당 값을 다른 곳에 저장하고 빌드 시간 (또는 상황에 따라 API를 통해)에 가져 오는 것이 더 유용 할 수 있습니다.
여기에는 몇 가지 이유가 있습니다.
<label for="name">
{{content [currentLanguage] .contactform.name}}
레이블></label>const text = content.en.contactfrom // 우리는 이것을 한 번 수행하고 파일의 모든 테스트에서 읽을 수 있습니다. cy.contains (text.namelabel, '[role = "status"]').
모든 상황은 다르지만 끈에 상수 시스템을 갖는 것은 강력한 UI 테스트를 작성할 때 큰 자산이므로 권장합니다. 그런 다음, 우리의 상황에 번역 또는 동적 컨텐츠가 필요할 때, 우리는 훨씬 더 잘 준비됩니다.
테스트에서 텍스트 문자열을 가져 오는 것에 대한 좋은 주장을 들었습니다. 예를 들어, 테스트 자체가 콘텐츠 소스와 독립적으로 예상 컨텐츠를 지정하는 경우 일부 찾기 테스트가 더 읽기 쉽고 일반적으로 더 좋습니다.
공정한 요점입니다. 나는 더 많은 편집 검토/출판 모델을 통해 내용을 제어해야한다고 생각하기 때문에 이것에 대해 덜 설득력이 없으며, 테스트가 작성 될 때 올바른 특정 문자열이 아니라 소스의 예상 컨텐츠가 렌더링되었는지 확인하기를 원합니다. 그러나 많은 사람들이 이것에 대해 저와 동의하지 않으며, 팀 내에서 트레이드 오프가 이해되는 한, 선택은 수용 가능합니다.
즉, 여전히 프론트 엔드의 컨텐츠에서 코드를 분리하는 것이 여전히 좋습니다. 또한 구성 요소 테스트에서 문자열을 가져오고 엔드 투 엔드 테스트에서 가져 오지 않는 것과 같이 믹스 앤 일치하는 것이 유효 할 수도 있습니다. 이런 식으로, 우리는 일부 복제를 저장하고 우리의 구성 요소가 올바른 컨텐츠를 표시한다는 확신을 얻는 동시에, 편집자 사용자 대면 의미에서 예상 텍스트를 독립적으로 주장하는 프론트 엔드 테스트를 가지고 있습니다.
[data-test = "success-message"]와 같은 CSS 선택기는 여전히 유용하며 항상 사용하는 대신 의도적 인 방식으로 사용될 때 매우 유용 할 수 있습니다. 우리의 판단은 요소를 타겟팅하는 의미 있고 접근 가능한 방법이 없다는 것이라면 데이터 테스트 속성이 여전히 최선의 선택입니다. 예를 들어, DOM 구조가 테스트를 작성하는 날에 DOM 구조가 발생하는 것과 같은 우연의 일치에 따라 훨씬 낫습니다.“카드 클래스의 세 번째 DIV의 두 번째 목록 항목”스타일의 테스트 스타일로 돌아갑니다.
콘텐츠가 역동적 일 것으로 예상되는 경우도 있으며 테스트에서 사용하기 위해 공통된 진실의 소스에서 문자열을 쉽게 잡을 수있는 방법이 없습니다. 이러한 상황에서 데이터 테스트 속성은 우리가 관심있는 특정 요소에 도달하는 데 도움이됩니다. 예를 들어 접근성 친화적 인 주장과 결합 할 수 있습니다.
cy.get ( 'h2 [data-test = "intro-subheading"]')
여기서 우리는 소개 서체의 데이터 테스트 속성이 무엇인지 찾고 싶지만 여전히 우리가 기대할 것으로 예상되는 경우 H2 요소가되어야한다고 주장합니다. 데이터 테스트 속성은 페이지에있을 수있는 다른 H2가 아니라 관심있는 특정 H2를 얻는 데 사용됩니다. 어떤 이유로 h2의 내용을 테스트 시점에 알 수 없다면.
콘텐츠를 아는 경우에도 여전히 데이터 속성을 사용하여 응용 프로그램이 해당 콘텐츠를 올바른 위치에 렌더링 할 수 있습니다.
cy.contains ( 'h2 [data-test = "intro-subeading"]', 'Testing에 오신 것을 환영합니다!')
데이터 테스트 선택기는 또한 페이지의 특정 부분으로 내려 가서 그 안에서 주장을하는 편의성이 될 수 있습니다. 이것은 다음과 같을 수 있습니다.
cy.get ( 'article [data-test = "ablum-card-blur-great-escape"]'). 내 (() => {
cy.cintains ( 'H2', 'Great Escape').
cy.cintains ( 'p', '1995 Blur').
cy.get ( '[data-test = "stars"]').
})그 시점에서 우리는이 컨텐츠를 목표로하는 다른 좋은 방법이있을 수 있기 때문에 약간의 뉘앙스에 빠지게됩니다. 그것은 단지 예일뿐입니다. 그러나 하루가 끝나면 적어도 우리가 테스트중인 HTML에 포함 된 접근성 기능을 이해하고 테스트에 포함시키려는 접근성 기능을 이해하고 있기 때문에 우리가있는 곳과 같은 세부 사항에 대해 걱정하면 좋습니다.
프론트 엔드 테스트는 우리가 어떤 요소와 상호 작용 해야하는 요소와 기대할 내용을 테스트하는 방법에 대해 사려 깊다면 더 많은 가치를 가져옵니다. 대화 형 구성 요소를 대상으로하는 이름을 선호해야하며, 비 결과 컨텐츠에 대한 특정 요소 이름, ARIA 역할 등을 포함해야합니다. 이 로케이터는 실용적 일 때 강도와 브리틀즈의 올바른 조합을 만듭니다.
물론 다른 모든 것에서 데이터 테스트가 있습니다.
위 내용은 프론트 엔드 테스트 로케이터를 최대화하십시오의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
