Cypress vừa phát hành một tính năng beta có tên là tap, cho phép các tác nhân lập trình AI (AI-driven coding agents) kết nối vào một phiên chạy Cypress trực tiếp, lấy các bản chụp DOM (DOM snapshots) và nhật ký lệnh (command logs), từ đó sử dụng thông tin hình ảnh này để chẩn đoán các lỗi xảy ra. Công cụ này chỉ hoạt động với Cypress 15.21.0 trở lên, trình duyệt dựa trên Chromium và giao diện “cypress open”; nó không chạy ở chế độ headless.

Tại sao các tác nhân AI cần nhiều hơn một mã thoát (exit code)

Hầu hết các trợ lý lập trình AI đều xử lý một lượt chạy Cypress giống như bất kỳ công cụ dòng lệnh nào khác: chúng thực thi npx cypress run, đọc trạng thái thoát của tiến trình và quyết định xem bài kiểm tra có vượt qua hay không. Một mã thoát cho tác nhân biết rằng có lỗi xảy ra, nhưng nó không cung cấp manh mối liệu một bộ chọn (selector) bị viết sai, một trang không tải được, hay một lớp phủ (overlay) đã chặn một nút bấm. Ngược lại, con người sẽ mở giao diện Cypress UI, quan sát trình duyệt, kiểm tra cây DOM và đọc nhật ký lệnh trước khi đưa ra giả thuyết.

Khoảng cách đó khiến việc gỡ lỗi tự động trở nên kém ổn định. "Element not found" có thể bắt nguồn từ hàng tá nguyên nhân gốc rễ, và nếu không có bằng chứng hình ảnh, AI có thể sẽ tiếp tục thử cùng một cách sửa lỗi, dẫn đến vòng lặp vô tận.

Cách tap thu hẹp khoảng cách

Tap tạo ra một giao diện dựa trên terminal cho một thực thể Cypress đang chạy. Sau khi nhà phát triển khởi chạy Cypress ở chế độ open:

npx cypress open --e2e --browser=chrome

tác nhân có thể phát hành một loạt các lệnh đầu ra JSON từ một shell riêng biệt:

  • npx cypress tap specs --json – liệt kê các tệp spec hiện có.
  • npx cypress tap run <spec> --json – bắt đầu chạy một spec duy nhất.
  • npx cypress tap status --json – trả về trạng thái của lượt chạy hiện tại, bao gồm cả dấu thời gian (timestamps).

Vì dữ liệu trạng thái chứa dấu thời gian startedAt, tác nhân có thể xác minh rằng nó đang xem các kết quả mới nhất thay vì một lượt chạy cũ đã kết thúc trước đó. Chỉ dựa vào mã thoát thô là không còn đủ nữa.

Khi một bài kiểm tra thất bại, tác nhân có thể đào sâu hơn:

  • npx cypress tap reporter --json – lấy báo cáo kiểm tra tổng thể.
  • npx cypress tap command --test-id <ID> --command-id <ID> --json – lấy chính xác lệnh đã bị lỗi, cùng với bản chụp DOM của ứng dụng, cây ARIA và bất kỳ thuộc tính phần tử liên quan nào tại thời điểm đó.

Được trang bị bản chụp đó, AI có thể suy luận tại sao bộ chọn bị trượt, liệu trang có đang tải hay không, hoặc liệu một hộp thoại (modal) có đang che khuất mục tiêu hay không. Sau đó, nó có thể đề xuất một thay đổi mã, áp dụng nó và chạy lại cùng một spec để xác minh bản sửa lỗi.

Chính sách an toàn cho các tác nhân tự trị

Để ngăn vòng lặp chạy mãi mãi, đội ngũ Cypress đề xuất một quy trình làm việc kỷ luật:

  1. Chỉ chạy một tệp spec cụ thể.
  2. Kiểm tra định kỳ tap status với một thời hạn (deadline) nghiêm ngặt, bỏ qua bất kỳ kết quả nào có startedAt cũ hơn lần kiểm tra trước đó.
  3. Chỉ kiểm tra bài kiểm tra bị lỗi và lệnh gây lỗi.
  4. Chỉ cho phép một lần sửa đổi mã trước lượt chạy tiếp theo.
  5. Chạy lại spec.
  6. Nếu kết quả thay đổi, hãy dừng lại và báo cho con người để xem xét.

Tác nhân cũng nên tạo một giải thích bằng ngôn ngữ tự nhiên về những gì nó đã quan sát được và tại sao bản sửa lỗi được đề xuất sẽ hoạt động. Vượt qua bài kiểm tra là chưa đủ; AI phải chứng minh được rằng nó đã hiểu các bằng chứng hình ảnh.

Ai sẽ được hưởng lợi

Các nhà phát triển vốn đã dựa vào các trợ lý AI để tạo mã giờ đây có thể cung cấp cho các trợ lý đó một bề mặt gỡ lỗi phong phú hơn. Lợi ích kỳ vọng là giảm thời gian dành cho việc theo đuổi các bài kiểm tra chập chờn (flaky tests), đặc biệt là trong các bộ kiểm tra end-to-end lớn, nơi việc tái hiện lỗi thủ công có thể mất nhiều phút. Các nhóm áp dụng tap có thể thấy thời gian xử lý các pull request liên quan đến các thành phần UI nhanh hơn, và giảm nhu cầu về các phiên gỡ lỗi qua lại.

Rủi ro và hạn chế

Tap vẫn đang ở bản beta, điều đó có nghĩa là nó có thể chứa lỗi, thay đổi cú pháp lệnh hoặc ngừng hỗ trợ một số cấu hình nhất định mà không báo trước. Việc phụ thuộc vào giao diện open UI loại trừ các đường ống CI headless, vì vậy các nhóm sẽ cần một chiến lược riêng cho các bản build tự động. Vì tính năng này truyền dữ liệu DOM trực tiếp, sẽ có một mức tiêu tốn hiệu năng nhất định có thể làm chậm các spec lớn. Cuối cùng, chính sách an toàn giả định rằng AI có thể tuân thủ thời hạn và dừng lại sau một lần thay đổi duy nhất; một tác nhân được thiết kế kém vẫn có thể rơi vào vòng lặp vô tận hoặc áp dụng một bản sửa lỗi không chính xác.

Những gì cần theo dõi tiếp theo

  • Các chu kỳ phản hồi bản Beta – Cypress có khả năng sẽ tinh chỉnh schema JSON và thêm các lệnh chi tiết hơn dựa trên ý kiến đóng góp từ những người dùng đầu tiên.
  • Tích hợp với CI – Có thể mong đợi các script từ cộng đồng giúp kết nối yêu cầu chế độ mở (open-mode) của tap với các trình chạy không giao diện (headless runners), có lẽ bằng cách khởi tạo một màn hình ảo.
  • Công cụ cho AI-agent – Các nhà cung cấp đang xây dựng trợ lý lập trình có thể bắt đầu tích hợp sẵn hỗ trợ tap như một module gỡ lỗi mặc định, giúp tính năng này trở nên phổ biến hơn trong các tiện ích mở rộng IDE chính thống.

Nếu bạn đang thử nghiệm việc bảo trì kiểm thử bằng AI, hãy dùng thử tap trên một spec không ổn định (flaky) duy nhất và xem liệu ngữ cảnh trực quan có giúp rút ngắn chu kỳ gỡ lỗi hay không. Công cụ này sẽ không thay thế sự phán đoán của con người, nhưng nó sẽ cung cấp cho coding agent của bạn một "đôi mắt" mà trước đây nó còn thiếu.