Cypress 테스트 작성에 대한 1,000피트 개요 #frontend@twiliosendgrid

게시 됨: 2020-10-03

Twilio SendGrid에서 수백 개의 Cypress 종단 간(E2E) 테스트를 작성했으며 다양한 웹 응용 프로그램 및 팀에서 새로운 기능이 출시됨에 따라 계속해서 더 많이 작성하고 있습니다. 이 테스트는 전체 스택을 대상으로 하여 고객이 겪는 가장 일반적인 사용 사례가 애플리케이션에서 새로운 코드 변경 사항을 푸시한 후에도 여전히 작동하는지 확인합니다.

먼저 한 걸음 물러서서 일반적으로 E2E 테스트에 대해 생각하는 방법에 대해 자세히 읽고 싶다면 언제든지 이 블로그 게시물을 확인하고 준비가 되면 여기로 돌아오십시오. 이 블로그 게시물은 E2E 테스트 전문가가 필요하지 않지만 테스트에서 특정 방식으로 작업을 수행한 이유를 알 수 있으므로 올바른 마음가짐을 갖는 데 도움이 됩니다. Cypress 테스트를 소개하는 단계별 자습서를 찾고 있다면 Cypress 문서를 확인하는 것이 좋습니다 . 이 블로그 게시물에서는 이전에 많은 Cypress 테스트를 보거나 작성했을 수 있으며 다른 사람들이 자신의 응용 프로그램에 대해 Cypress 테스트를 작성하는 방법이 궁금하다고 가정합니다.

Cypress 테스트를 많이 작성하고 나면 유사한 Cypress 기능, 주장 및 패턴을 사용하여 필요한 것을 달성하는 자신을 발견하게 될 것입니다. 개발 또는 스테이징과 같은 별도의 환경에 대한 테스트를 작성하기 위해 Cypress에서 이전에 사용하거나 수행한 가장 일반적인 부분과 전략을 보여줍니다. Cypress 테스트 작성 방법에 대한 이 1,000피트 개요가 자신의 테스트와 비교할 아이디어를 제공하고 Cypress 테스트에 접근하는 방식을 개선하는 데 도움이 되기를 바랍니다.

개요:

  1. Cypress API 정리
  2. 요소와 상호 작용
  3. 요소에 대한 어설션
  4. API 및 서비스 다루기
  5. cy.request(…)로 HTTP 요청하기
  6. cy.task()로 재사용 가능한 플러그인 만들기
  7. cy.server() 및 cy.route()로 네트워크 요청 모의
  8. 사용자 정의 명령
  9. 페이지 개체 정보
  10. window.Cypress를 사용하여 클라이언트 측 코드를 실행하지 않도록 선택
  11. iframe 다루기
  12. 테스트 환경에서 표준화

Cypress API 정리

Cypress API에서 가장 일반적으로 사용되는 부분부터 살펴보겠습니다.

요소 선택

DOM 요소를 선택하는 방법에는 여러 가지가 있지만 이러한 Cypress 명령을 통해 수행해야 하는 대부분의 작업을 수행할 수 있으며 일반적으로 이 후에 더 많은 작업과 주장을 연결할 수 있습니다.

  • cy.get(“[data-hook='someSelector']”) 또는 cy.find(“.selector”) 를 사용하여 일부 CSS 선택기를 기반으로 요소를 가져옵니다.
  • cy.contains(“someText”) 와 같은 일부 텍스트를 기반으로 요소 선택 또는 cy.contains(“.selector”, “someText”) 와 같은 일부 텍스트를 포함하는 특정 선택기로 요소 가져오기.
  • 상위 요소가 "내부"로 보이도록 하여 미래의 모든 쿼리는 cy.get(“.selector”).within(() => { cy.get(“.child”) }) 와 같이 상위 요소의 하위 요소로 범위가 지정됩니다. cy.get(“.selector”).within(() => { cy.get(“.child”) }) .
  • 요소 목록을 찾고 "각각" 하나를 통해 cy.get(“tr”).each(($tableRow) => { cy.wrap($tableRow).find('td').eq(1).should(“contain”, “someText” }) 와 같은 더 많은 쿼리 및 주장을 수행하기 위해 cy.get(“tr”).each(($tableRow) => { cy.wrap($tableRow).find('td').eq(1).should(“contain”, “someText” }) .
  • 때때로 요소가 페이지에서 보이지 않을 수 있으므로 cy.get(“.buttonFarBelow”).scrollIntoView() 와 같이 먼저 요소를 스크롤하여 보기로 이동해야 합니다.
  • 때로는 기본 명령 시간 초과보다 더 긴 시간 초과가 필요하므로 cy.get(“.someElement”, { timeout: 10000 }) 와 같은 { timeout: timeoutInMs } 를 선택적으로 추가할 수 있습니다.

요소와 상호 작용

이것은 Cypress 테스트 전체에서 가장 많이 사용되는 상호 작용입니다. 때때로 요소에 대한 일부 검사를 우회하기 위해 해당 함수 호출에서 { force: true } 속성을 던져야 합니다. 이는 요소가 어떤 방식으로든 다루어지거나 요소를 렌더링하는 방법 측면에서 제어할 수 없는 외부 라이브러리에서 파생된 경우에 자주 발생합니다.

  • 모달, 테이블 등의 버튼과 같은 많은 것을 클릭해야 하므로 cy.get(“.button”).click() 과 같은 작업을 수행합니다.
  • 양식은 사용자 세부 정보 및 기타 데이터 필드를 작성하기 위해 웹 응용 프로그램의 모든 곳에 있습니다. cy.get(“input”).type(“somekeyboardtyping”) 을 사용하여 해당 입력을 입력하고 cy.get(“input”).clear().type(“somenewinput”) 와 같이 먼저 지워서 입력의 일부 기본값을 지워야 할 수도 있습니다. cy.get(“input”).clear().type(“somenewinput”) . cy.get(“input”).type(“text{enter}”) 을 수행할 때 Enter 키에 대해 {enter} 와 같은 다른 키를 입력하는 멋진 방법도 있습니다.
  • cy.get(“select”).select(“value”) 와 같은 선택 옵션과 cy.get(“.checkbox”).check() 와 같은 체크박스와 상호 작용할 수 있습니다.

요소에 대한 어설션

이것은 Cypress 테스트에서 올바른 콘텐츠가 있는 페이지에 항목이 있는지 확인하는 데 사용할 수 있는 일반적인 어설션입니다.

  • 페이지에 항목이 표시되는지 여부를 확인하려면 cy.get(“.selector”).should(“be.visible”) 및 cy.get(“.selector”).should(“not.be.visible”) .
  • DOM 요소가 마크업의 어딘가에 존재하는지 확인하고 요소가 보이는지 여부에 반드시 신경 쓰지 않는다면 cy.get(“.element”).should(“exist”) 또는 cy.get(“.element”).should(“not.exist”) .
  • 요소에 일부 텍스트가 포함되어 있는지 여부를 확인하려면 cy.get(“button”).should(“contain”, “someText”) 및 cy.get(“button”).should(“not.contain”, “someText”) .
  • 입력 또는 버튼이 비활성화 또는 활성화되었는지 확인하려면 cy.get(“button”).should(“be.disabled”) 와 같이 주장할 수 있습니다.
  • 체크된 항목이 있는지 확인하려면 cy.get(“.checkbox”).should(“be.checked”) 와 같이 테스트할 수 있습니다.
  • 일반적으로 더 확실한 텍스트와 가시성 검사에 의존할 수 있지만 때로는 cy.get(“element”).should(“have.class”, “class-name”) 와 같은 클래스 검사에 의존해야 합니다. .should(“have.attr”, “attribute”) 를 사용하여 속성을 테스트하는 다른 유사한 방법이 있습니다.
  • cy.get(“div”).should(“be.visible”).and(“contain”, “text”) 와 같이 주장을 함께 연결하는 것이 종종 유용합니다.

API 및 서비스 다루기

이메일과 관련된 자체 API 및 서비스를 처리할 때 cy.request(...) 를 사용하여 인증 헤더가 있는 백엔드 엔드포인트에 HTTP 요청을 할 수 있습니다. 또 다른 대안은 이메일 받은 편지함에 연결하고 이메일을 찾는 것과 같은 다른 라이브러리가 있는 노드 서버에서 가장 잘 처리될 수 있는 다른 기능을 다루기 위해 모든 사양 파일에서 호출할 수 있는 cy.task(...) 플러그인을 구축할 수 있다는 것입니다. 테스트에 사용할 일부 값을 반환하기 전에 이메일을 일치시키거나 응답 및 특정 API 호출에 대한 폴링을 더 많이 제어할 수 있습니다.

cy.request(…)로 HTTP 요청하기

cy.request() 를 사용하여 테스트 케이스가 실행되기 전에 데이터를 설정하거나 해제하기 위해 백엔드 API에 HTTP 요청을 할 수 있습니다. 일반적으로 엔드포인트 URL, "GET" 또는 "POST"와 같은 HTTP 메소드, 헤더, 때로는 백엔드 API로 보낼 요청 본문을 전달합니다. 그런 다음 이것을 .then((response) => { }) 와 연결하여 "status" 및 "body"와 같은 속성을 통해 네트워크 응답에 액세스할 수 있습니다. 여기에서 cy.request() 호출의 예를 보여줍니다.

때때로 테스트를 실행하기 전에 정리하는 동안 cy.request(...) 가 4xx 또는 5xx 상태 코드와 함께 실패하는지 여부에 신경 쓰지 않을 수 있습니다. 실패한 상태 코드를 무시하도록 선택할 수 있는 한 가지 시나리오는 테스트에서 항목이 아직 존재하고 이미 삭제되었는지 확인하기 위해 GET 요청을 할 때입니다. 항목이 이미 정리되었을 수 있으며 404 찾을 수 없음 상태 코드와 함께 GET 요청이 실패합니다. 이 경우 테스트 단계를 실행하기 전에 Cypress 테스트가 실패하지 않도록 failOnStatusCode: false 의 다른 옵션을 설정합니다.

cy.task()로 재사용 가능한 플러그인 만들기

노드 서버를 통해 이메일 받은 편지함 공급자와 같은 다른 서비스와 통신하기 위해 재사용 가능한 기능에 대해 더 많은 유연성과 제어를 원할 때(이 예는 이후 블로그 게시물에서 다룰 예정임) 자체 추가 기능을 제공하고 싶습니다. API 호출에 대한 사용자 지정 응답을 사용하여 Cypress 테스트에 연결하고 적용할 수 있습니다. 또는 노드 서버에서 다른 코드를 실행하는 것을 좋아합니다. 종종 이를 위해 cy.task() 플러그인을 빌드합니다. 우리는 모듈 파일에 플러그인 기능을 생성하고 아래와 같이 기능을 실행하는 데 필요한 인수로 작업 플러그인을 정의하는 plugins/index.ts 에서 이를 가져옵니다.

이러한 플러그인은 사양 파일의 모든 위치에서 cy.task(“pluginName”, { ...args }) 로 호출할 수 있으며 동일한 기능이 발생할 것으로 예상할 수 있습니다. 반면에 cy.request() 를 사용한 경우 모든 곳에서 가져올 페이지 개체 또는 도우미 파일에 이러한 호출 자체를 래핑하지 않는 한 재사용성이 떨어집니다.

또 다른 주의 사항은 플러그인 작업 코드가 노드 서버에서 실행되기 때문에 Cypress.env(“apiHost”) 또는 cy.getCookie('auth_token') 와 같은 함수 내에서 일반적인 Cypress 명령을 호출할 수 없다는 것입니다. 백엔드 API와 통신해야 하는 경우 요청 본문에 필요한 것 외에 인증 토큰 문자열 또는 백엔드 API 호스트와 같은 항목을 플러그인 함수의 인수 객체에 전달합니다.

cy.server() 및 cy.route()로 네트워크 요청 모의

재현하기 어려운 데이터(페이지의 중요한 UI 상태의 변형 또는 느린 API 호출 처리)가 필요한 Cypress 테스트의 경우 고려해야 할 Cypress 기능 중 하나는 네트워크 요청을 스텁 아웃하는 것입니다. 이것은 바닐라 XMLHttpRequest, axios 라이브러리 또는 jQuery AJAX를 사용하는 경우 XmlHttpRequest(XHR) 기반 요청과 잘 작동합니다. 그런 다음 cy.server() 및 cy.route() 를 사용하여 원하는 상태에 대한 응답을 조롱하는 경로를 수신 대기합니다. 다음은 예입니다.

또 다른 사용 사례는 cy.server() , cy.route() 및 cy.wait() 를 함께 사용하여 수신 대기하고 다음 단계를 수행하기 전에 네트워크 요청이 완료될 때까지 기다리는 것입니다. 일반적으로 페이지를 로드하거나 페이지에서 어떤 종류의 작업을 수행한 후 직관적인 시각적 신호는 무언가가 완료되었거나 우리가 주장하고 조치를 취할 준비가 되었음을 나타냅니다. 이러한 가시적인 큐가 없는 경우 API 호출이 이와 같이 완료될 때까지 명시적으로 기다릴 수 있습니다.

한 가지 큰 문제는 네트워크 요청에 fetch를 사용하는 경우 네트워크 요청을 조롱하거나 동일한 방식으로 완료될 때까지 기다릴 수 없다는 것입니다. 이 문제에 기록된 대로 테스트를 실행하기 전에 일반 window.fetch 를 XHR 폴리필로 교체하고 일부 설정 및 정리 단계를 수행하는 해결 방법이 필요합니다 . 또한 Cypress 4.9.0에는 experimentalFetchPolyfill FetchPolyfill 속성이 있어 작동할 수 있지만 전반적으로 문제 없이 애플리케이션에서 가져오기 및 XHR 사용에 대한 네트워크 스터빙을 처리하는 더 나은 방법을 찾고 있습니다. Cypress 5.1.0에는 XHR 및 가져오기 요청 모두에 대한 실험적 네트워크 스터빙을 위한 유망한 새 cy.route2() 함수( Cypress 문서 참조 )가 있으므로 Cypress 버전을 업그레이드하고 다음을 확인하기 위해 실험할 계획입니다. 그것은 우리의 문제를 해결합니다.

사용자 정의 명령

WebdriverIO와 같은 라이브러리와 유사하게, 테스트 사례가 실행되기 전에 API를 통해 로그인을 처리하는 사용자 지정 명령과 같이 사양 파일 전체에서 재사용 및 연결될 수 있는 전역 사용자 지정 명령을 생성할 수 있습니다. support/commands.ts 와 같은 파일에서 이를 개발하면 cy.customCommand() 또는 cy.login() ) 과 같은 함수에 액세스할 수 있습니다. 로그인을 위한 사용자 지정 명령을 작성하는 방법은 다음과 같습니다.

페이지 개체 정보

페이지 개체는 페이지와 상호 작용하는 데 도움이 되는 선택기 및 기능을 둘러싼 래퍼입니다. 테스트를 작성하기 위해 페이지 개체를 빌드할 필요는 없지만 UI에 대한 변경 사항을 캡슐화하는 방법을 고려하는 것이 좋습니다. 선택기와 상호 작용을 한 곳이 아닌 여러 파일에서 업데이트하지 않도록 그룹화하는 측면에서 삶을 더 쉽게 만들고 싶습니다.

공유 및 확장할 상속된 페이지 클래스에 대해 open() 과 같은 공통 기능을 사용하여 기본 "페이지" 클래스를 정의할 수 있습니다. 파생된 페이지 클래스는 여기에 표시된 것처럼 super.open() 과 같은 호출을 통해 기본 클래스의 기능을 재사용하면서 선택기 및 기타 도우미 함수에 대한 자체 getter 함수를 정의합니다.

window.Cypress를 사용하여 클라이언트 측 코드를 실행하지 않도록 선택

CSV와 같은 자동 다운로드 파일을 사용하여 흐름을 테스트할 때 다운로드는 종종 테스트 실행을 중단하여 Cypress 테스트를 중단했습니다. 타협으로, 우리는 주로 사용자가 다운로드에 대한 적절한 성공 상태에 도달할 수 있는지 테스트하고 테스트 실행에서 window.Cypress 검사를 추가하여 실제로 파일을 다운로드하지 않았는지 테스트하고 싶었습니다.

Cypress 테스트가 실행되는 동안 브라우저에 window.Cypress 속성이 추가됩니다. 클라이언트 측 코드에서 창 개체에 Cypress 속성이 없는지 확인한 다음 평소와 같이 다운로드를 수행하도록 선택할 수 있습니다. 그러나 Cypress 테스트에서 실행 중인 경우 실제로 파일을 다운로드하지 마십시오. 또한 웹 앱에서 실행되는 A/B 실험을 위해 window.Cypress 속성을 확인하는 이점도 있었습니다. 우리는 테스트 사용자에게 잠재적으로 다른 경험을 보여줄 수 있는 A/B 실험에서 더 이상 허약함과 비결정적 동작을 추가하고 싶지 않았기 때문에 아래 강조 표시된 대로 실험 로직을 실행하기 전에 먼저 속성이 존재하지 않는지 확인했습니다.

iframe 다루기

내장된 iframe 지원이 없기 때문에 Cypress에서는 iframe을 처리하는 것이 어려울 수 있습니다. 현재 Cypress 버전에 따라 작동하거나 작동하지 않을 수 있는 단일 iframe 및 중첩 iframe을 처리하기 위한 해결 방법으로 채워진 실행 중인 [문제]( https://github.com/cypress-io/cypress/issues/136 )가 있습니다. 또는 상호 작용하려는 iframe. 사용 사례의 경우 이메일 API 및 마케팅 캠페인 API 업그레이드 흐름을 확인하기 위해 스테이징 환경에서 Zuora 청구 iframe을 처리하는 방법이 필요했습니다. 테스트에는 앱에서 새 제품으로의 업그레이드를 완료하기 전에 샘플 청구 정보를 작성하는 작업이 포함됩니다.

iframe 처리를 캡슐화하기 위해 cy.iframe(iframeSelector) 사용자 지정 명령을 만들었습니다. iframe에 선택기를 전달하면 iframe이 더 이상 비어 있지 않을 때까지 iframe의 본문 내용을 확인한 다음 본문 내용을 반환하여 아래와 같이 더 많은 Cypress 명령과 연결할 수 있습니다.

TypeScript로 작업할 때 index.d.ts 파일에 다음과 같이 iframe 사용자 지정 명령을 입력할 수 있습니다.

테스트의 청구 부분을 수행하기 위해 iframe 사용자 지정 명령을 사용하여 Zuora iframe의 본문 내용을 가져온 다음 iframe 내에서 요소를 선택하고 값을 직접 변경했습니다. 우리는 이전에 cy.find(...).type(...) 을 사용하고 작동하지 않는 다른 대안을 사용하는 데 문제가 있었지만 고맙게도 cy.get(selector).invoke('val', 'some value') . 또한 교차 출처 오류를 우회할 수 있도록 cypress.json 구성 파일에 ”chromeWebSecurity”: false 가 필요합니다. 필러 선택기와 함께 사용하는 샘플 스니펫은 다음과 같습니다.

테스트 환경에서 표준화

앞에서 강조한 가장 일반적인 주장, 기능 및 접근 방식을 사용하여 Cypress로 테스트를 작성한 후 테스트를 실행하고 하나의 환경에 대해 통과하도록 할 수 있습니다. 이것은 훌륭한 첫 번째 단계이지만 새 코드를 배포하고 변경 사항을 테스트할 여러 환경이 있습니다. 각 환경에는 자체 데이터베이스, 서버 및 사용자 집합이 있지만 Cypress 테스트는 동일한 일반 단계로 작동하도록 한 번만 작성해야 합니다.

최종적으로 프로덕션에 변경 사항을 배포하기 전에 개발, 테스트 및 스테이징과 같은 여러 테스트 환경에 대해 Cypress 테스트를 실행하려면 환경 변수를 추가하고 이러한 사용 사례를 지원하기 위해 구성 값을 변경하는 Cypress의 기능을 활용해야 합니다.

다양한 프론트엔드 환경에 대해 테스트를 실행하려면 :

https://staging.app.com 또는 https://testing.app.com 과 같은 URL과 일치하도록 Cypress.config(“baseUrl”) 를 통해 액세스 한 "baseUrl" 값 을 변경해야 합니다 . 이것은 경로를 추가하기 위해 모든 cy.visit(...) 호출에 대한 기본 URL을 변경합니다. Cypress 명령을 실행하기 전에 CYPRESS_BASE_URL=<frontend_url> 을 설정하거나 --config baseUrl=<frontend_url> 을 설정하는 등 여러 가지 방법으로 이를 설정할 수 있습니다.

다양한 백엔드 환경에 대해 테스트를 실행하려면 다음 단계를 따르세요 .

https://staging.api.com 또는 https://testing.api.com 과 같은 API 호스트 이름을 알아야 "apiHost" 와 같은 환경 변수를 설정하고 Cypress.env(“apiHost”) . 이들은 "<apiHost>/some/endpoint"와 같은 특정 경로에 대한 HTTP 요청을 만들기 위해 cy.request(...) 호출에 사용되거나 다른 인수로 cy.task(...) 함수 호출을 통해 전달됩니다. 어떤 백엔드를 적중할지 알기 위한 속성입니다. 이러한 인증된 호출은 또한 cy.getCookie(“auth_token”) 를 통해 localStorage 또는 쿠키에 저장하고 있을 가능성이 가장 높은 인증 토큰을 알아야 합니다. 이 인증 토큰이 "Authorization" 헤더의 일부로 또는 요청의 일부로 다른 수단을 통해 결국 전달되는지 확인하십시오. cypress.json 파일에서 직접 또는 Cypress 설명서에서 참조할 수 있는 --env 명령줄 옵션과 같이 이러한 환경 변수를 설정하는 방법에는 여러 가지가 있습니다 .

다른 사용자에게 로그인하거나 다양한 메타데이터를 사용하는 방법:

여러 프론트엔드 URL과 백엔드 API 호스트를 처리하는 방법을 알았으니 이제 다른 사용자에 대한 로그인을 어떻게 처리합니까? 테스트 환경에서 고유할 수 있는 도메인, API 키 및 기타 리소스와 관련된 항목과 같이 환경에 따라 다양한 메타데이터를 사용하는 방법은 무엇입니까?

"testing" 및 "staging"의 가능한 값을 사용하여 "testEnv" 라는 다른 환경 변수를 만드는 것으로 시작하여 테스트에 적용할 환경의 사용자 및 메타데이터를 알려주는 방법으로 이를 사용할 수 있습니다. "testEnv" 환경 변수를 사용하면 몇 가지 방법으로 이에 접근할 수 있습니다.

Fixtures 폴더 아래에 별도의 "staging.json", "testing.json" 및 기타 환경 JSON 파일을 생성하고 fixtures cy.fixture(`${testEnv}.json`).then(...) )와 같은 "testEnv" 값을 기반으로 사용할 수 있도록 가져올 수 있습니다. cy.fixture(`${testEnv}.json`).then(...) . 그러나 JSON 파일을 제대로 입력할 수 없으며 구문 오류와 테스트당 필요한 모든 속성을 작성하는 데 훨씬 더 많은 여지가 있습니다. 또한 JSON 파일은 테스트 코드와 거리가 멀기 때문에 테스트를 편집할 때 최소 2개의 파일을 관리해야 합니다. 모든 환경 테스트 데이터가 cypress.json 의 환경 변수에 직접 설정되고 과다한 테스트에서 관리하기에 너무 많은 경우 유사한 유지 관리 문제가 발생합니다.

다른 옵션은 특정 환경에 대한 해당 테스트의 사용자 및 메타데이터를 로드하기 위해 테스트 또는 스테이징을 기반으로 하는 속성을 사용하여 사양 파일 내에 테스트 픽스처 개체를 만드는 것입니다. 이들은 객체이기 때문에 모든 사양 파일이 메타데이터 유형을 재사용하고 정의하기 위해 테스트 픽스처 객체 주위에 더 나은 일반 TypeScript 유형을 정의할 수도 있습니다. Cypress.env(“testEnv”) 를 호출하여 실행 중인 테스트 환경을 확인하고 해당 값을 사용하여 전체 테스트 픽스처 개체에서 해당 환경의 테스트 픽스처를 추출하고 해당 값을 테스트에 사용합니다. 테스트 픽스처 객체의 일반적인 개념은 아래의 코드 스니펫에 요약되어 있습니다.

"baseUrl" Cypress 구성 값, "apiHost" 백엔드 환경 변수 및 "testEnv" 환경 변수를 함께 적용하면 아래와 같이 여러 조건을 추가하거나 별도의 논리 흐름을 추가하지 않고도 여러 환경에 대해 작동하는 Cypress 테스트를 가질 수 있습니다.

한 걸음 뒤로 물러나서 npm을 통해 실행하도록 자신만의 Cypress 명령을 만드는 방법을 살펴보겠습니다. 비슷한 개념을 yarn, Makefile 및 응용 프로그램에 사용할 수 있는 기타 스크립트에 적용할 수 있습니다. "open" 및 "run" 명령의 변형을 정의하여 GUI를 "open"하고 package.json 의 다양한 프론트엔드 및 백엔드 환경에 대해 헤드리스 모드에서 "run"을 정렬할 수 있습니다. 각 환경의 구성에 대해 여러 JSON 파일을 설정할 수도 있지만 단순성을 위해 인라인으로 옵션 및 값이 포함된 명령이 표시됩니다.

package.json 스크립트에서 프론트엔드 "baseUrl"이 "http://localhost:9001" 범위에서 앱을 로컬로 시작할 때 " https://staging.app. 컴 ”. 백엔드 "apiHost" 및 "testEnv" 변수를 설정하여 백엔드 엔드포인트에 요청하고 특정 테스트 픽스처 객체를 로드할 수 있습니다. 또한 기록 키를 사용하여 Docker 컨테이너에서 테스트를 실행해야 하는 경우 특수 "cicd" 명령을 생성할 수도 있습니다.

몇 가지 테이크아웃

요소를 선택하고, 요소와 상호 작용하고, 페이지의 요소에 대해 주장할 때 cy.get() , cy.contains() ) 와 같은 작은 Cypress 명령 목록을 사용하여 많은 Cypress 테스트를 작성할 수 있습니다. .click() , .type() , .should('be.visible') .

cy.request()를 사용하여 백엔드 API에 HTTP 요청을 하고, cy.request() 를 사용하여 노드 서버에서 임의의 코드를 실행하고, cy.task() cy.server() 및 cy.route() )를 사용하여 네트워크 요청을 제거하는 방법도 있습니다. . API를 통해 사용자에게 로그인하는 데 도움이 되도록 cy.login() 과 같은 고유한 사용자 지정 명령을 만들 수도 있습니다. 이러한 모든 사항은 테스트를 실행하기 전에 사용자를 적절한 시작점으로 재설정하는 데 도움이 됩니다. 이러한 선택기와 기능을 모두 파일로 묶고 사양에서 사용할 재사용 가능한 페이지 개체를 만들었습니다.

둘 이상의 환경에서 통과하는 테스트를 작성하는 데 도움이 되도록 환경별 메타데이터를 보유하는 환경 변수 및 개체를 활용하십시오.

이렇게 하면 Cypress 사양에서 별도의 데이터 리소스를 사용하여 다양한 사용자 집합을 실행할 수 있습니다. package.json 의 npm run cypress:open:staging 과 같은 별도의 Cypress npm 명령은 적절한 환경 변수 값을 로드하고 실행하기로 선택한 환경에 대한 테스트를 실행합니다.

이것으로 Cypress 테스트 작성에 대한 1,000피트 개요를 마칩니다. 이것이 Cypress 테스트에 적용하고 개선할 수 있는 실용적인 예제와 패턴을 제공했기를 바랍니다.

Cypress 테스트에 대해 더 알고 싶으십니까? 다음 리소스를 확인하세요.

  • E2E 테스트를 작성할 때 고려해야 할 사항
  • Cypress 테스트의 모든 것을 TypeScript
  • Cypress 테스트에서 이메일 흐름 다루기
  • Cypress 테스트 구성, 구성 및 통합을 위한 아이디어
  • Docker, Buildkite 및 CICD와 Cypress 테스트 통합