나는 수년간의 추세를 볼 수 있을 만큼 오랫동안 프런트 엔드 개발에 참여해 왔습니다. 젊은 개발자들이 프로그래밍의 역사적 맥락을 이해하지 못한 채 새로운 패러다임을 가지고 작업하고 있다는 것입니다. 물론 아무것도 모른다는 것은 충분히 이해할 수 있는 일이다. 웹은 다양한 기술과 전문성을 갖춘 매우 큰 공간이며, 우리가 무엇을 모르는지 항상 알 수는 없습니다. 이 분야의 학습은 한 번 일어나고 끝나는 것이 아니라 지속적인 여정입니다. 적절한 사례: 우리 팀의 누군가가 사용자가 UI의 특정 탭에서 벗어나는지 알 수 있는지 물었습니다. JavaScript의 beforeunload 이벤트를 지적했습니다. 그러나 이전에 이 문제를 해결해 본 사람들은 beforeunload가 일반적인 사용 사례인 다른 사이트에 저장되지 않은 데이터에 대한 경고를 받았기 때문에 이것이 가능하다는 것을 알고 있습니다. 또한 좋은 측정을 위해 동료에게 pageHide 및 visibleChange 이벤트를 지적했습니다. 내가 그걸 어떻게 알았지? 처음 JavaScript를 배울 때 공부해서가 아니라 다른 프로젝트에서 나왔기 때문입니다. 사실 현대 프런트엔드 프레임워크는 이전의 거대 기술 기업의 어깨 위에 서 있습니다. 그들은 전통적으로 모든 사람이 알아야 할 필수적인 프런트 엔드 개념을 알거나 만질 필요성을 줄이거나 심지어 제거하는 더 나은 개발자 경험을 위해 개발 관행을 추상화합니다. CSSOM(CSS 개체 모델)을 고려해보세요. CSS와 JavaScript로 작업하는 사람이라면 누구나 CSSOM 실무 경험이 많을 것으로 예상할 수 있지만 항상 그런 것은 아닙니다. 제가 작업한 전자상거래 사이트에 대한 React 프로젝트가 있었는데, 여기서 현재 선택한 결제 제공업체에 대한 스타일시트를 로드해야 했습니다. 문제는 특정 페이지에만 실제로 필요한 스타일시트가 모든 페이지에 로드된다는 점이었습니다. 이 일을 맡은 개발자는 스타일시트를 동적으로 로드한 적이 없었습니다. 다시 말하지만, React가 여러분이 도달했을 수 있는 전통적인 접근 방식을 추상화하면 이는 완전히 이해할 수 있습니다. CSSOM은 일상 업무에 필요한 것이 아닐 가능성이 높습니다. 그러나 일회성 인스턴스라도 어느 시점에서는 상호 작용해야 할 가능성이 높습니다. 이러한 경험은 제가 이 글을 쓰게 된 계기가 되었습니다. 일상 업무에서 직접적으로 접할 수 없는 기존 웹 기능과 기술이 많이 있습니다. 아마도 당신은 웹 개발에 상당히 익숙하지 않고, 깊이 알 필요도 없거나 전혀 알 필요가 없는 특정 프레임워크의 추상화에 빠져 있기 때문에 단순히 웹 개발에 대해 인식하지 못할 수도 있습니다. 저는 구체적으로 XML에 대해 이야기하고 있습니다. 우리 중 많은 사람들이 알고 있는 XML은 HTML과 완전히 다르지 않은 고대 언어입니다. XSLT 프로그래밍으로 알려진 XML 스택의 상당 부분을 브라우저에서 제거해야 한다고 제안하는 최근 WHATWG 토론 때문에 이 문제를 언급하게 되었습니다. 이것은 우리 팀이 처한 CSSOM 상황만큼 실용적인 용도로 사용할 수 있는, 우리가 수년 동안 사용해 온 일종의 오래된 기존 기술입니다. 이전에 XSLT를 사용해 본 적이 있나요? 우리가 이 오래된 기술에 크게 의존하고 XML 컨텍스트 외부의 기능을 활용하여 오늘날 실제 문제를 해결하는지 살펴보겠습니다. XPath: 중앙 API 단순 XML 관점을 벗어나 아마도 가장 유용할 수 있는 가장 중요한 XML 기술은 하나의 루트 요소가 있는 마크업 트리에서 모든 노드나 속성을 찾을 수 있게 해주는 쿼리 언어인 XPath입니다. 나는 XSLT에 대해 개인적인 애정을 갖고 있지만 그것도 XPath에 의존하고 있으므로 중요도 순위에서 개인적인 애정은 제쳐두어야 합니다. XSLT 제거 주장에는 XPath에 대한 언급이 없으므로 여전히 허용되는 것으로 가정합니다. 특히 일반적인 XML 사용 이외의 용도를 찾으려고 할 때 XPath는 이 기술 제품군의 핵심이자 가장 중요한 API이기 때문에 좋습니다. CSS 선택기를 사용하여 페이지에 있는 대부분의 요소를 찾을 수 있지만 모든 요소를 찾을 수는 없기 때문에 이는 중요합니다. 또한 CSS 선택기를 사용하여 DOM의 현재 위치를 기반으로 요소를 찾을 수 없습니다. XPath는 가능합니다. 이제 이 글을 읽고 있는 여러분 중 일부는 XPath를 알고 있을 수도 있고, 일부는 그렇지 않을 수도 있습니다. XPath는 꽤 큰 기술 영역이므로, 이와 같은 단일 기사에서는 모든 기본 사항을 가르칠 수 없으며 XPath와 관련된 멋진 내용도 보여줄 수 없습니다. 실제로 그 기사를 쓰려고 했는데, 스매싱 매거진의 평균 출판물은 5,000 단어를 넘지 않습니다. 나는 이미2,000 단어는 기본의 절반에 불과합니다. 그래서 저는 XPath로 멋진 작업을 시작하고 이 내용이 흥미로울 경우 기본 사항에 사용할 수 있는 몇 가지 링크를 제공하겠습니다. XPath와 CSS 결합 XPath는 요소를 쿼리할 때 CSS 선택기가 할 수 없는 많은 작업을 수행할 수 있습니다. 그러나 CSS 선택자는 XPath가 할 수 없는 몇 가지 작업, 즉 클래스 이름으로 요소를 쿼리하는 작업도 수행할 수 있습니다.
CSS XPath .myClass /*[contains(@class, "myClass")]
이 예에서 CSS는 .myClass 클래스 이름이 포함된 요소를 쿼리합니다. 한편, XPath 예제는 "myClass"라는 문자열이 있는 속성 클래스를 포함하는 요소를 쿼리합니다. 즉, .myClass 클래스 이름이 있는 요소뿐만 아니라 문자열에 "myClass"가 있는 요소(예: .myClass2)를 포함하여 모든 속성에서 myClass가 있는 요소를 선택합니다. XPath는 그런 의미에서 더 광범위합니다. 그렇지 않습니다. 저는 CSS를 버리고 XPath를 통해 모든 요소를 선택해야 한다고 제안하는 것이 아닙니다. 그게 요점이 아닙니다. 요점은 XPath가 CSS가 할 수 없는 일을 할 수 있고 여전히 매우 유용할 수 있다는 것입니다. 비록 그것이 브라우저 스택의 오래된 기술이고 언뜻 보기에는 분명하지 않을 수도 있습니다. 두 가지 기술을 함께 사용할 수 있을 뿐만 아니라 그 과정에서 XPath에 대해 배우고 XPath를 스택의 또 다른 도구로 만들 수 있기 때문에 함께 사용합시다. 문제는 JavaScript의 document.evaluate 메서드와 JavaScript용 CSS API와 함께 사용하는 다양한 쿼리 선택기 메서드가 호환되지 않는다는 것입니다. 시작하기 위해 호환 가능한 쿼리 API를 만들었지만, 여기서 하는 일에서 벗어나기 때문에 그것에 대해 많이 생각하지 않았습니다. 다음은 재사용 가능한 쿼리 생성자의 매우 간단한 작업 예입니다. Bryan Rasmussen의 Pen queryXPath [forked]를 참조하세요. 문서 개체에 queryCSSSelectors(기본적으로 querySelectorAll) 및 queryXPaths라는 두 가지 메서드를 추가했습니다. 둘 다 queryResults 객체를 반환합니다.
{ 쿼리 유형: 노드 | 문자열 | 번호 | 부울, 결과: any[] // html 요소, xml 요소, 문자열, 숫자, 부울, queryCSSSelectors: (쿼리: 문자열, 수정: 부울) => queryResults, queryXpaths: (쿼리: 문자열, 수정: 부울) => queryResults }
queryCSSSelectors 및 queryXpaths 함수는 결과 배열이 노드 유형인 한 결과 배열의 요소에 대해 사용자가 제공한 쿼리를 실행합니다. 그렇지 않으면 빈 배열과 노드 유형이 포함된 queryResult를 반환합니다. amend 속성이 true로 설정되면 함수는 자체 queryResults를 변경합니다. 어떤 경우에도 프로덕션 환경에서는 이 기능을 사용해서는 안 됩니다. 이 방법은 순전히 두 쿼리 API를 함께 사용하는 경우의 다양한 효과를 보여주기 위한 것입니다. 예제 쿼리 나는 XPath 쿼리가 수행할 수 있는 강력한 작업 중 일부와 다른 접근 방식 대신 사용할 수 있는 방법을 보여주는 다양한 XPath 쿼리의 몇 가지 예를 보여주고 싶습니다. 첫 번째 예는 //li/text()입니다. 이는 모든 li 요소를 쿼리하고 해당 텍스트 노드를 반환합니다. 따라서 다음 HTML을 쿼리한다면:
- 하나
- 둘
- 세
...이것이 반환되는 것입니다:
{"queryType":"xpathEvaluate","results":["one","two"," three"],"resultType":"string"}
즉, ["one","two"," three"] 배열을 얻습니다. 일반적으로 이를 얻기 위해 li 요소를 쿼리하고, 해당 쿼리의 결과를 배열로 변환하고, 배열을 매핑하고, 각 요소의 텍스트 노드를 반환합니다. 하지만 XPath를 사용하면 더 간결하게 이를 수행할 수 있습니다. document.queryXPaths("//li/text()").results.
텍스트 노드를 얻는 방법은 함수 서명처럼 보이는 text()를 사용하는 것입니다. 요소의 텍스트 노드를 반환합니다. 이 예에서는 마크업에 세 개의 li 요소가 있으며 각 요소에는 텍스트("one", "two" 및 " three")가 포함되어 있습니다.
text() 쿼리의 예를 하나 더 살펴보겠습니다. 이것이 우리의 마크업이라고 가정합니다:
href 속성 값을 반환하는 쿼리를 작성해 보겠습니다. document.queryXPaths("//a[text() = 'Sign In']/@href").results.
이것은 마지막 예와 마찬가지로 현재 문서에 대한 XPath 쿼리이지만 이번에는 "Sign In" 텍스트가 포함된 링크(요소)의 href 속성을 반환합니다. 실제 반환된결과는 ["/login.html"]입니다. XPath 함수 개요 XPath 함수에는 여러 가지가 있으며 아마도 익숙하지 않을 것입니다. 내 생각에는 다음을 포함하여 알아야 할 몇 가지 사항이 있습니다.
start-with텍스트가 특정 다른 텍스트 예제로 시작하는 경우, start-with(@href, 'http:')는 href 속성이 http:로 시작하면 true를 반환합니다. 포함(contains) 텍스트에 다른 특정 텍스트 예제가 포함되어 있는 경우, 텍스트 노드에 "Smashing Magazine"이라는 단어가 어디에든 포함되어 있으면 contain(text(), "Smashing Magazine")은 true를 반환합니다. count는 쿼리와 일치하는 항목 수를 반환합니다. 예를 들어, count(//*[starts-with(@href, 'http:'])는 http:로 시작하는 텍스트를 포함하는 href 속성이 있는 요소가 있는 컨텍스트 노드의 링크 수를 반환합니다. substring은 문자열을 인수로 전달한다는 점을 제외하면 JavaScript 하위 문자열과 유사하게 작동합니다. 예를 들어, substring("my text", 2, 4)는 "y t"를 반환합니다. substring-before다른 문자열 앞의 문자열 부분을 반환합니다. 예를 들어, substing-before("my text", " ")는 "my"를 반환합니다. 마찬가지로 substring-before("hi","bye")는 빈 문자열을 반환합니다. substring-after다른 문자열 뒤의 문자열 부분을 반환합니다. 예를 들어, substing-after("my text", " ")는 "text"를 반환합니다. 마찬가지로 substring-after("hi","bye")는 빈 문자열을 반환합니다. Normalize-space선행 및 후행 공백을 제거하고 공백 문자 시퀀스를 단일 공백으로 대체하여 정규화된 공백이 있는 인수 문자열을 반환합니다. not은 인수가 false이면 true를 반환하고, 그렇지 않으면 false를 반환합니다. true부울 true를 반환합니다. false부울 false를 반환합니다. concat문자열에 대한 메서드로 실행하지 않는다는 점을 제외하면 JavaScript concat과 동일합니다. 대신 연결하려는 문자열을 모두 입력합니다. string-length는 JavaScript string-length와 동일하지 않지만 인수로 제공된 문자열의 길이를 반환합니다. 번역은 문자열을 취하고 두 번째 인수를 세 번째 인수로 변경합니다. 예를 들어,translate("abcdef", "abc", "XYZ")는 XYZdef를 출력합니다.
이러한 특정 XPath 함수 외에도 바닥, 천장, 라운드, 합계 등과 같이 JavaScript 대응 요소(또는 기본적으로 모든 프로그래밍 언어의 대응 요소)와 동일하게 작동하는 다른 함수도 많이 있습니다. 다음 데모에서는 이러한 각 기능을 보여줍니다. Bryan Rasmussen이 작성한 Pen XPath Numerical function [forked]을 참조하세요. 대부분의 문자열 조작 함수와 마찬가지로 많은 숫자 함수도 단일 입력을 취합니다. 물론 이는 마지막 XPath 예제에서처럼 쿼리에 사용되어야 하기 때문입니다. //li[floor(text()) > 250]/@val
대부분의 예제에서와 같이 이를 사용하면 경로와 일치하는 첫 번째 노드에서 실행하게 됩니다. JavaScript에는 이미 자체적인 유형 변환 문제가 있으므로 피해야 할 몇 가지 유형 변환 함수도 있습니다. 그러나 다른 숫자와 비교하기 위해 문자열을 숫자로 변환하려는 경우가 있을 수 있습니다. 무언가의 유형을 설정하는 함수에는 부울, 숫자, 문자열 및 노드가 있습니다. 이는 중요한 XPath 데이터 유형입니다. 그리고 여러분이 상상할 수 있듯이 이러한 함수의 대부분은 DOM 노드가 아닌 데이터 유형에 사용될 수 있습니다. 예를 들어 substring-after는 이미 설명한 대로 문자열을 취하지만 href 속성의 문자열일 수도 있습니다. 문자열일 수도 있습니다.
const testSubstringAfter = document.queryXPaths("substring-after('hello world',' ')");
분명히 이 예제는 결과 배열을 ["world"]로 반환합니다. 이를 실제로 보여주기 위해 DOM 노드가 아닌 것에 대한 함수를 사용하여 데모 페이지를 만들었습니다. Bryan Rasmussen의 Pen queryXPath [forked]를 참조하세요. 번역 기능의 놀라운 측면에 주목해야 합니다. 즉, 두 번째 인수(예: 번역하려는 문자 목록)에 문자가 있고 번역할 일치하는 문자가 없으면 해당 문자가 출력에서 제거된다는 것입니다. 따라서 이는 다음과 같습니다.
번역('안녕하세요, 제 이름은 이니고 몬토야입니다. 당신이 제 아버지를 죽였습니다. 죽을 준비를 하세요','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','*')
... 공백을 포함한 문자열이 생성됩니다. [" * * ** "]
이는 문자 "a"가 별표(*)로 변환되지만 대상 문자열에서 변환이 없는 다른 모든 문자는 완전히 제거됨을 의미합니다. 공백은 우리에게 남은 전부입니다번역된 "a" 문자 사이. 그런 다음 다시 이 쿼리를 수행합니다.
번역('안녕하세요, 제 이름은 이니고 몬토야입니다. 당신이 제 아버지를 죽였습니다. 죽을 준비를 하세요','abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ,','**************************************************')")
...문제가 없으며 다음과 같은 결과를 출력합니다.
"***** ** **** ** ***** ******* *** ****** ** ****** ******* ** ***"
XPath 변환 기능이 수행하는 작업을 정확하게 수행하는 데 JavaScript에는 쉬운 방법이 없다는 사실이 생각날 수도 있습니다. 하지만 많은 사용 사례에서는 정규식을 사용하는 replacementAll을 사용하여 처리할 수 있습니다. 내가 시연한 것과 동일한 접근 방식을 사용할 수 있지만 원하는 것이 문자열을 번역하는 것뿐이라면 이는 차선책입니다. 다음 데모는 XPath의 번역 기능을 래핑하여 JavaScript 버전을 제공합니다. Bryan Rasmussen의 펜 번역 기능 [forked]을 참조하세요. 이런 것을 어디에 사용할 수 있나요? 3자리 오프셋을 사용한 Caesar Cipher 암호화를 고려하십시오(예: 기원전 48년의 최고 수준 암호화).
번역("카이사르는 루비콘 강을 건너려고 계획 중입니다!", "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz", "XYZABCDEFGHIJKLMNOPQRSTUVWxyzabcdefghijklmnopqrstuvw")
입력 텍스트 "카이사르가 루비콘 강을 건너려고 합니다!" 결과는 "Zxbpxo fp mixkkfkd ql zolpp qeb Oryfzlk!"입니다. 다양한 가능성에 대한 또 다른 빠른 예를 제공하기 위해 문자열 입력을 취하고 번역 함수를 사용하여 움라우트를 사용하는 모든 문자를 포함하여 텍스트를 반환하는 메탈 함수를 만들었습니다. Bryan Rasmussen의 펜 금속 기능 [포크됨]을 참조하세요.
const 금속 = (str) => { returntranslate(str, "AOUaou","äÖÜäöü"); }
그리고 "Motley Crue rule, rock on guys!"라는 텍스트가 제공되면 "Mötley Crüe rüles, röck ön düdes!"가 반환됩니다. 분명히 이 기능을 온갖 종류의 패러디 용도로 사용할 수도 있습니다. 그게 당신이라면 이 TVTropes 기사가 당신에게 많은 영감을 줄 것입니다. XPath와 함께 CSS 사용 CSS 선택기를 XPath와 함께 사용하는 주된 이유를 기억하십시오. CSS는 클래스가 무엇인지 거의 이해하는 반면, XPath로 할 수 있는 최선의 방법은 클래스 속성의 문자열 비교입니다. 대부분의 경우 작동합니다. 그러나 예를 들어 누군가가 .primaryLinks 및 .primaryLinks2라는 클래스를 생성하고 XPath를 사용하여 .primaryLinks 클래스를 가져오는 상황이 발생한다면 문제가 발생할 가능성이 높습니다. 그런 어리석은 일이 없다면 아마도 XPath를 사용할 것입니다. 하지만 사람들이 그런 어리석은 짓을 하는 곳에서 일했다는 사실을 알리게 되어 슬프네요. 다음은 CSS와 XPath를 함께 사용하는 또 다른 데모입니다. 문서의 노드가 아닌 컨텍스트 노드에서 XPath를 실행하기 위해 코드를 사용할 때 어떤 일이 발생하는지 보여줍니다. Bryan Rasmussen이 작성한 Pen CSS와 xpath를 함께 참조하세요. CSS 쿼리는 .관련articles a이며, 이는 .관련articles 클래스가 할당된 div의 두 a 요소를 가져옵니다. 그 다음에는 세 개의 "잘못된" 쿼리, 즉 이러한 요소를 컨텍스트 노드로 실행할 때 원하는 작업을 수행하지 않는 쿼리가 있습니다. 그들이 예상한 것과 다르게 행동하는 이유를 설명할 수 있습니다. 문제의 세 가지 잘못된 쿼리는 다음과 같습니다.
//text(): 문서의 모든 텍스트를 반환합니다. //a/text(): 문서의 링크 내부에 있는 모든 텍스트를 반환합니다. ./a/text(): 결과를 반환하지 않습니다.
이러한 결과가 나오는 이유는 컨텍스트가 CSS 쿼리에서 반환된 요소이지만 // 전체 문서에 어긋나기 때문입니다. 이것이 XPath의 강점입니다. CSS는 노드에서 조상으로 이동한 다음 해당 조상의 형제로 이동할 수 없으며 해당 형제의 자손으로 내려갈 수 없습니다. 그러나 XPath는 가능합니다. 한편 ./는 현재 노드의 하위 항목을 쿼리합니다. 여기서 점(.)은 현재 노드를 나타내고 슬래시(/)는 일부 하위 노드로 이동함을 나타냅니다. 속성인지, 요소인지, 텍스트인지는 경로의 다음 부분에 따라 결정됩니다. 그러나 CSS 쿼리에서 선택한 하위 요소가 없으므로 해당 쿼리도 아무것도 반환하지 않습니다. 마지막 데모에는 세 가지 좋은 쿼리가 있습니다.
.//텍스트(), ./텍스트(), 정규화 공간(./text()).
정규화 공간 쿼리는 XPath 함수 사용법을 보여주지만 다른 쿼리에 포함된 문제도 수정합니다. HTML은 다음과 같이 구성됩니다.
Selenium WebDriver로 기능 테스트 자동화
쿼리는 텍스트 노드의 시작과 끝 부분에 줄 바꿈을 반환합니다.Normalize-space는 이를 제거합니다. 입력 XPath와 함께 부울 이외의 값을 반환하는 XPath 함수를 사용하면 다른 함수에도 적용됩니다. 다음 데모에서는 다양한 예를 보여줍니다. Bryan Rasmussen이 작성한 Pen xpath 함수 예제 [forked]를 참조하세요. 첫 번째 예는 주의해야 할 문제를 보여줍니다. 구체적으로 다음 코드는 다음과 같습니다.
document.queryXPaths("substring-after(//a/@href,'https://')");
...하나의 문자열을 반환합니다:
"www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/"
말이 되네요, 그렇죠? 이러한 함수는 배열을 반환하지 않고 단일 문자열이나 단일 숫자를 반환합니다. 여러 결과가 있는 곳 어디에서나 함수를 실행하면 첫 번째 결과만 반환됩니다. 두 번째 결과는 우리가 정말로 원하는 것을 보여줍니다.
document.queryCSSSelectors("a").queryXPaths("substring-after(./@href,'https://')");
두 문자열의 배열을 반환합니다.
["www.smashingmagazine.com/2018/04/feature-testing-selenium-webdriver/","www.smashingmagazine.com/2022/11/automated-test-results-improve-accessibility/"]
XPath 함수는 JavaScript의 함수처럼 중첩될 수 있습니다. 따라서 Smashing Magazine URL 구조를 알고 있다면 다음을 수행할 수 있습니다(템플릿 리터럴 사용 권장). `번역( 하위 문자열( 하위 문자열 이후(./@href, 'www.smashingmagazine.com/') ,9), '/','')`
이는 수행하는 작업을 설명하는 주석이 필요할 정도로 너무 복잡해집니다. www.smashingmagazine.com/ 뒤의 href 속성에서 모든 URL을 가져와서 처음 9자를 제거한 다음 슬래시(/) 문자를 아무것도 없는 것으로 변환하여 끝 슬래시를 제거합니다. 결과 배열은 다음과 같습니다.
["기능 테스트-셀레늄-웹 드라이버","자동 테스트-결과-접근성 향상"]
더 많은 XPath 사용 사례 XPath는 테스트에서 정말 빛을 발할 수 있습니다. 그 이유는 어렵지 않습니다. XPath를 사용하면 DOM의 모든 위치에서 DOM의 모든 요소를 가져올 수 있지만 CSS는 그렇지 않기 때문입니다. 많은 최신 빌드 시스템에서 CSS 클래스가 일관되게 유지될 것이라고 기대할 수는 없지만 XPath를 사용하면 변경되는 DOM 구조에 관계없이 요소의 텍스트 콘텐츠가 무엇인지에 대해 보다 강력한 일치를 만들 수 있습니다. 탄력적인 XPath 테스트를 수행할 수 있는 기술에 대한 연구가 있었습니다. 이름이 바뀌거나 제거되어 CSS 선택기가 더 이상 작동하지 않는다는 이유만으로 테스트가 실패하고 실패하는 것보다 더 나쁜 것은 없습니다. XPath는 다중 로케이터 추출에도 정말 뛰어납니다. XPath 쿼리를 사용하여 요소를 일치시키는 방법은 여러 가지가 있습니다. CSS에서도 마찬가지입니다. 그러나 XPath 쿼리는 반환되는 항목을 제한하는 보다 타겟화된 방식으로 사물을 드릴링하여 가능한 일치 항목이 여러 개 있을 수 있는 특정 일치 항목을 찾을 수 있도록 해줍니다. 예를 들어 XPath를 사용하여 형제 div 바로 뒤에 있는 div 내에 포함된 특정 h2 요소를 반환할 수 있습니다. 이 요소에는 data-testID="leader" 속성이 있는 하위 이미지 요소가 포함되어 있습니다.
이 헤드라인을 보지 마세요
이 헤드라인도 받지 마세요
리더 이미지의 헤더
쿼리는 다음과 같습니다. document.queryXPaths(` //div[ 다음 형제::div[1] /img[@data-testID='리더'] ] /h2/ 텍스트() `);
데모를 통해 이 모든 것이 어떻게 결합되는지 살펴보겠습니다. Bryan Rasmussen이 작성한 Pen Complex H2 쿼리 [forked]를 참조하세요. 그렇죠. XPath를 사용하는 테스트에는 모든 요소에 대한 가능한 경로가 많이 있습니다. XSLT 1.0 지원 중단 저는 앞서 Chrome 팀이 브라우저에서 XSLT 1.0 지원을 제거할 계획이라고 언급했습니다. XSLT 1.0은 문서 변환을 위해 XML 중심 프로그래밍을 사용하고 이는 대부분의 브라우저에서 발견되는 XPath 1.0에 의존하기 때문에 이는 중요합니다. 그런 일이 발생하면 XPath의 핵심 구성 요소가 손실됩니다. 그러나 XPath가 테스트 작성에 정말 훌륭하다는 사실을 고려하면 XPath 전체가 조만간 사라질 가능성은 거의 없습니다. 즉, 기능이 제거되면 사람들이 해당 기능에 관심을 갖는 것을 발견했습니다. 그리고 XSLT 1.0이 더 이상 사용되지 않는 경우에는 확실히 그렇습니다. Hacker News에서는 지원 중단에 반대하는 주장으로 가득 찬 전체 토론이 진행되고 있습니다. 게시물 자체는 XSLT를 사용하여 블로그 프레임워크를 만드는 훌륭한 예입니다. 너토론을 직접 읽을 수 있지만 이러한 종류의 사례를 처리하기 위해 JavaScript를 XLST용 심으로 사용하는 방법에 대해 알아봅니다. 또한 브라우저가 JavaScript의 Saxon XSLT, XQUERY 및 XPath 엔진에 대한 포트인 SaxonJS를 사용해야 한다는 제안도 보았습니다. 특히 Saxon-JS가 이러한 사양의 현재 버전을 구현하는 반면, 1.0 이상의 XPath 또는 XSLT 버전을 구현하는 브라우저는 없고 XQuery를 구현하는 브라우저도 없기 때문에 이는 흥미로운 아이디어입니다. 나는 SaxonJS와 다른 버전의 Saxon 엔진을 개발한 Saxonica의 Norm Tovey-Walsh에게 연락했습니다. 그는 말했다: “최신 XML 기술을 브라우저에 통합하기 위한 출발점으로 SaxonJS를 사용하는 데 관심이 있는 브라우저 공급업체가 있다면 우리는 그들과 논의하게 되어 기쁩니다.”— Norm Tovey-Walsh
그러나 다음도 추가했습니다. "누군가 SaxonJS를 현재 형식으로 가져와 변경 없이 브라우저 빌드에 넣는 것이 이상적인 접근 방식이라고 생각한다면 매우 놀랄 것입니다. 브라우저 공급업체는 브라우저를 구축한다는 사실의 특성상 우리가 '외부에서' 할 수 있는 것보다 훨씬 더 깊은 수준에서 통합에 접근할 수 있습니다."— Norm Tovey-Walsh
Tovey-Walsh의 의견은 XSLT 지원 중단 발표 약 일주일 전에 나왔다는 점은 주목할 가치가 있습니다. 결론 나는 계속해서 갈 수 있었다. 그러나 이것이 XPath의 힘을 입증하고 XPath를 사용하여 훌륭한 일을 달성하는 방법을 보여주는 많은 예를 제공했기를 바랍니다. 이는 브라우저 스택의 오래된 기술이 존재한다는 사실을 전혀 알지 못했거나 접근을 고려한 적이 없더라도 오늘날에도 여전히 많은 유용성을 갖고 있는 완벽한 예입니다. 추가 자료
Maroun Ayli, Youssef Bakouny, Nader Jalloul 및 Rima Kilany의 "자연어를 사용한 자동화된 웹 테스트의 탄력성 향상"(ACM 디지털 라이브러리) 이 기사에서는 탄력성 테스트 작성을 위한 다양한 XPath 예제를 제공합니다. XPath(MDN)XPath 작동 방식을 자세히 설명하는 기술적인 설명을 원하는 경우 시작하기에 좋은 곳입니다. XPath 튜토리얼(ZVON)풍부한 예제와 명확한 설명 덕분에 이 튜토리얼이 내 학습에 가장 도움이 된다는 것을 알았습니다. XPather이 대화형 도구를 사용하면 코드로 직접 작업할 수 있습니다.
