XPath là một ngôn ngữ truy vấn được các nhà phát triển và kỹ sư tự động hóa QA sử dụng rộng rãi. Thông thường, XPath trở thành công cụ chính để truy vấn các nút DOM bên trong các dự án Selenium. Khả năng di chuyển lên hoặc xuống để áp dụng các bộ lọc và chức năng khác nhau khiến nó trở thành một lựa chọn vững chắc.

Điều gì đã thay đổi?

Giao diện người dùng ngày càng trở nên phức tạp hơn. Điều này có thể làm cho các nhà phát triển phải đau đầu thực sự, những người phải thiết kế ứng dụng của họ để có thể dễ dàng hỗ trợ và mở rộng. 

Công nghệ thành phần web khá mới, nhưng nó đã gây ồn ào trong ngành công nghiệp. Nó cung cấp cho các nhà phát triển khả năng tạo các phần tử HTML gốc, có thể tái sử dụng và có thể được cắm vào một cách khai báo. Một trong những công nghệ quan trọng nhất của các thành phần web là ShadowDOM.

ShadowDOM là một tính năng mới của API DOM cung cấp khả năng đóng gói cây con DOM của bạn. Do đó, bạn có thể thiết kế các phần tử HTML mới, có thể tái sử dụng, có thể có DOM riêng biệt với các kiểu riêng biệt.

DOM với ShadowDOM

Hãy xem ví dụ đơn giản với ShadowDOM:

Hmm, nó có khác một chút so với XML rõ ràng không? Gốc bóng tối giống như một gốc mới của cây con DOM khác? Trong trường hợp này, chúng ta thấy rằng cây DOM không phải là một XML rõ ràng nữa.

XPath và ShadowDOM

ShadowDOM phá vỡ cấu trúc XML của DOM. Làm cách nào để bạn truy cập vào các nút của cây Shadow trong phạm vi thông qua XPath? Điều gì sẽ xảy ra nếu tôi chỉ muốn tìm một số phần tử đầu vào với một số lớp cụ thể mà không cần chú ý đến độ sâu của cây con bóng tối?

Hãy thử nếu chúng ta có thể tìm thấy một khoảng bên trong ShadowDOM:

Oái oăm! Có vẻ như XPath không thể tìm kiếm sâu thông qua ShadowDOM. Nó có phù hợp với các nhiệm vụ giống như trước đây không? Nếu chúng ta cần làm việc với DOM của mình như một tài liệu toàn cầu của các phần tử mà không quan tâm đến độ sâu của ShadowDOM, chúng ta cần có khả năng truy vấn như trước đây.

Bạn có thể hỏi - nó có an toàn không? ShadowDOM được tạo ra vì lý do bảo mật và chúng tôi sẽ giảm tính đóng gói của nó và sử dụng nó như trước đây. Đối với mục đích tự động hóa thì không sao, vì mục tiêu chính là tìm phần tử (không phải để sửa đổi hoặc loại bỏ). Nó cũng có thể phù hợp với nhu cầu của nhà phát triển, nhưng chỉ trong một số trường hợp cụ thể; nó không nên là mô hình chính của các nút truy vấn trong mã thời gian chạy, nhưng ý tưởng phải giống nhau - chỉ sử dụng nó để tìm các phần tử.

Ngôn ngữ XDomPath

Chúng ta có những ngôn ngữ truy vấn nào cho cây DOM? Chỉ cụ thể cho cây DOM. Không chắc liệu chúng ta có thể đặt tên cho một thứ gì đó hơn là chỉ CSS hay không. CSS có tệ không? Không, nhưng Xpath mạnh hơn nhiều và nó sẽ rất hữu ích nếu chúng ta có thể tiếp tục sử dụng các tính năng này trong tương lai.

Đây là mục đích chính của tôi để tạo một ngôn ngữ dựa trên Xpath truy vấn DOM mới - XDomPath.

Bạn có thể đọc thêm chi tiết kỹ thuật về thiết lập và cài đặt trên GitHub của tôi .

Mô hình XML XDomPath

XDomPath cố gắng coi DOM với ShadowDOM là XML đơn giản (ảnh chụp màn hình bên dưới).

Vì vậy, thuật toán ánh xạ DOM sang XML trông như thế này:

1. Nút ShadowRoot luôn là nút con đầu tiên của máy chủ của nó.
2. Máy chủ của ShadowRoot là mẹ trực tiếp của nó.
3. Phần tử có rãnh là phần tử con trực tiếp của máy chủ (không phải phần tử con của vị trí).
4. Tất cả các mối quan hệ nút khác không bị ảnh hưởng.

Hãy thử một vài truy vấn

Ví dụ 1 . Truy vấn XDomPath tìm kiếm sâu đơn giản “.//div”

Chúng tôi thấy rằng XDomPath không yêu cầu chúng tôi di chuyển sâu vào bên trong phạm vi ShadowDOM cụ thể theo cách thủ công. Với thuật toán sau ở trên, chúng ta sẽ xử lý phần tử gốc bóng dưới dạng con của vùng chứa div (thứ nhất và thứ hai).

Ví dụ 2. Tìm kiếm rễ bóng. Truy vấn XDomPath “.// shadow ()”

Tương tự như hàm text () , chúng ta có thể sử dụng hàm shadow () mới , hàm này trả về một ShadowRoot NodeList.

Ví dụ 3. Tìm kiếm các nút văn bản. Truy vấn XDomPath “.//text()[.='some-text ']”

Ví dụ 4. Truy vấn các phần tử có rãnh. Truy vấnXDomPath “.// div / text ()”

Vì các phần tử có rãnh được coi là phần tử con trực tiếp của phần tử chủ, nên truy vấn này sẽ trả về một nút văn bản.

Ví dụ 5. Đảm bảo rằng phần tử nằm dưới gốc bóng. Truy vấn XDomPath “.//shadow()/p”

Ví dụ 6. Tìm vùng chứa có gốc bóng. Truy vấn XDomPath “.// div [./ shadow ()]”

API lập trình

XDomPath là một thư viện Javascript có sẵn dưới dạng phụ thuộc npm. Dưới đây là một ví dụ về việc bao gồm XDomPath vào một cơ sở mã.

1. Cách sử dụng XDomPath cơ bản:

2. Sử dụng các tính năng mới:

3. Tính năng dự kiến của việc xác định các chức năng thủ công:

Hỗ trợ chú thích Java của Selenium WebDriver

Để thêm hỗ trợ XDomPath cho các dự án Java tự động hóa Selenium, tôi đã tạo một chú thích mới FindByQuery mở rộng FindBy thông thường  với tùy chọn truy vấn mới - XDomPath.

Bạn có thể tìm thấy nó ở đây .

Đây là cách nó có thể được sử dụng bên trong cơ sở mã Java:

Phần kết luận

Tôi hy vọng rằng giải pháp của tôi sẽ giúp bạn kiểm tra / phát triển các ứng dụng web của mình. Cảm ơn vì đã đọc!