새로운 페이지 오브젝트를 등록하기 전에 자신을 확인합니다.

반응형

환영합니다! 다음 10분 동안 페이지 오브젝트 선택기를 견고하게 만들기 위해 어떤 방법을 사용하는지, 그리고 가장 빠른 방법으로 자신을 확인하는 방법에 대해 알아보겠습니다.

문제는

고객이 개발자의 새로운 기능이 테스트로 적용되기를 원합니다. 이미 테스트 사례를 작성했으며 이제 테스트 사례를 자동화해야 하는 과제를 안고 있습니다. 응용 프로그램 페이지의 요소와 이러한 요소로 작업하기 위해 테스트에 사용하는 방법에 대해 설명해야 하는 많은 루틴을 수행해야 합니다. 하지만 매번 테스트를 실행하지 않고 원하는 단계로 통과할 때까지 기다리는 방식으로 요소를 설명할 수 있는 방법이 있을까요? 알아보자

#1 개발자와 협상을 시도합니다.

 

이 점은 명백해 보인다. 우리는 한 가지 제품을 작업 중이고 개발자는 그것을 테스트하고 싶어 합니다. 그러나 실제로는 여러 가지 이유로 합의에 도달하는 것이 항상 가능한 것은 아닙니다. 추가 작업으로 인식하는 사람; 프로젝트에 너무 많은 레거시 코드가 있으며 요소에 추가 속성을 추가하는 데 오랜 시간이 걸립니다; 누군가는 1년 동안 작업을 해야 하고 데이터 테스트 ID 속성을 원하는 대로 추가할 여유 시간이 없습니다.d 요소 등

하지만 개발자들과는 아직 상의할 가치가 있습니다. 나는 그들이 중간에서 만나 테스트를 도와줄 준비가 되어 있는 상황을 한 번 이상 만났습니다. 대부분의 Ly는 개발 중에 QA 담당자들의 삶을 간단한 행동으로 크게 촉진할 수 있고 대화로 해결할 수 있다고 생각하는 사람이 없습니다.

어떤 경우든, 문화는 길러져야 한다는 것을 기억하세요. 씨앗이 열매를 맺고 새싹이 튼튼하게 자라기 위해 체계적으로 많은 노력을 기울였다.

개발자가 정확히 어떻게 우리를 도울 수 있을까요?

• data-test-id와 같은 주요 페이지 요소에 특수 특성을 추가하거나 ID 특성을 최대한 많이 채우도록 하십시오. 이러한 접근 방식은 테스트에 마크업과 덜 독립적이게 만듭니다. 내일 페이지가 완전히 제거되더라도 data-test-id는 여전히 원하는 요소를 가리킵니다.
• 클래스 또는 기타 특성에 더 자세한 설명 이름을 지정합니다. "빨간색 단추"와 같은 추상적인 클래스 이름을 사용하지 않도록 설득하고 "취소 단추"와 같은 의미 있는 이름을 부여합니다. 개발 및 QA 등 양 당사자에게 적합한 이름을 사전에 논의합니다.

 

#2 브라우저의 개발자 도구 사용

특정 페이지에서 개발자 도구를 사용하여 요소를 검색할 수 있습니다. 이 작업은 페이지 구조 탭 또는 Javascript 콘솔 탭에서 모두 수행할 수 있습니다.

• 구글 크롬에서 F12를 누르면 개발자 도구 창이 열립니다. Elements 탭에서 Ctrl + F를 누르면 요소 검색 막대가 열리고 CSS 로케이터, XPATH 또는 텍스트만 입력할 수 있습니다. 다른 브라우저들도 비슷한 도구를 가지고 있습니다.

• 콘솔 탭에는 CSS와 XPATH를 각각 검색하는 두 가지 JS 명령이 있습니다.

 

당신이 더 좋아하는 방법을 사용하세요. 저는 개인적으로 두 번째가 더 좋아요.

#3 동일한 로케이터를 다른 방식으로 설명하십시오.

이 조언을 읽을 때 가장 먼저 떠오르는 질문은 "왜"입니다. 답은 매우 간단하다. 왜냐하면 우리는 로케이터를 쓰는 실수를 할 수 있고 그것을 알아차리지도 못하기 때문이다. 이런저런 로케이터의 병목현상을 파악하고, 어떤 것이 우리에게 더 적합한지 파악하고, 작성 시 실수가 없었는지 확인하는 데 도움이 될 것입니다.

제가 무슨 말을 하는지 이해할 수 있도록 예를 들어 드리겠습니다. 어떤 페이지에서 필요한 요소를 찾으려고 합니다. 이를 위해 세 개의 유사한 로케이터를 작성했고 완전히 다른 수의 결과를 얻었습니다.

 

인터넷에는 CSS 및 XPATH 로케이터의 작동 방식에 대한 정보가 가득합니다. 이 예제의 핵심은 상당히 간단한 작업(다른 방식으로 동일한 페이지 요소를 검색)이 다른 결과로 이어진다는 것을 보여주는 것입니다. 앞으로 이 결과는 제가 검색을 할 때 실수를 한 것이 아닌지 생각할 수 있는 이유를 제공합니다.

이제 페이지를 탐색하고 로케이터를 조정하는 데 조금 더 많은 시간을 할애해야 하지만 이제 요소를 찾는 것이 더 신뢰할 수 있습니다.

#4 로케이터를 설명할 때 발생하는 실수에 대한 체크리스트를 만드세요.

이전 단락에서 설명한 것과 유사한 검색 요소 오류가 주기적으로 발생합니다. 이러한 오류 목록을 취합하여 새로운 로케이터를 설명하고 싶을 때마다 모든 오류를 검사함으로써 과거의 경험을 고려하게 되지만, 습관을 들이는 것, 즉 기존의 로케이터에서 발생할 수 있는 오류를 발견하게 됩니다. 매일 이 방법을 연습하면 곧 여러분은 마스터가 될 것입니다:)

 

#5 PageFactory 메소드를 통해 요소 초기화를 피합니다.

종종 로케이터를 확인하고 항목 검색이 제대로 작동하는지 확인하더라도 프로그래밍 언어로 작성된 테스트는 계속 실패합니다. Java, C#와 같은 언어로 작성하는 경우, Selenium 라이브러리를 사용하고 FindBy 주석을 통해 요소를 검색할 때 매우 일반적인 시나리오입니다.

왜 이런 일이 생기는 건가요? 생성자(일반적으로 생성자에서)에서 PageFactory.initElements() 메서드가 호출될 때 요소는 이 주석으로 초기화됩니다. 동적으로 로드되는 콘텐츠가 없던 먼 옛날에는 이것이 잘 먹혔지만, 이제는 반응형 애플리케이션의 시대에는 반응형 콘텐츠를 어디에서나 볼 수 있다. 자바에서 이러한 반응적인 페이지를 해석하려고 하면 어떻게 될까요? 페이지 객체를 만들 때 Selenium은 지정된 로케이터를 사용하여 브라우저에서 이 요소(cbAutomaticCheck)를 찾으려고 합니다. 그러나 페이지가 로드될 때 이 로케이터가 누락됩니다(나중에 요소가 표시됨). 그 결과 NoSuchElement가요소를 호출할 때 Selenium에 재검색 기능이 없으므로 이 요소에 액세스하는 동안 예외가 발생했습니다.

어떻게 처리하죠?

 

• 간단한 옵션은 이 주석을 사용하지 않고 프레임워크가 실제로 필요할 때(테스트에서 요소를 사용해야 할 때) 요소를 찾는 것입니다. 요소 검색을 다른 메서드로 이동하거나 WebElement에 대한 래퍼 클래스를 작성하여 요소에 액세스할 때 요소를 찾습니다.

• 어려운 옵션 - 별도의 컨텍스트. 페이지와 동시에 로드되는 요소 집합(및 FindBy 주석으로 해당 요소를 표시)과 서버에 대한 개별 요청으로 인해 나중에 나타나는 요소를 명확하게 이해해야 합니다. 이러한 종류의 요소(동적 요소)를 검색하려면 간편 옵션에 설명된 방법을 사용할 수 있습니다.

결론 및 다음 단계

 

이러한 간단한 규칙을 따르면 자동 테스트를 사용하여 프로젝트에서 요소를 설명하는 품질을 크게 향상시킬 수 있습니다.

보너스로 로케이터의 치트 시트에 링크를 첨부합니다.
https://devhints.io/css
https://devhints.io/xpath

행운을 빌고 멈추지 말고 자동화하세요!