HARmageddon bị hủy bỏ: cách chúng tôi dạy Playwright để chơi lại HAR với các thông số năng động

Các mỉm cười thường xuyên của HAR nhanh chóng ngừng hoạt động - các thông số động phá vỡ kết hợp yêu cầu, và nội dung chứa dữ liệu nhạy cảm không thể cam kết. Problem: Chúng tôi đã giới thiệu tiêu chuẩn hóa HAR tự động (thay thế người dùng, mã thông báo, ID) và một lớp logic trên cùng của Playwright xử lý chính xác các thông số động. Approach: Chúng tôi đã dạy Playwright để tìm đúng mục nhập HAR ngay cả khi các giá trị truy vấn / cơ thể thay đổi và ngăn chặn việc tái sử dụng các thực thể với các định danh động. What we did: Các thử nghiệm E2E trở nên độc lập với môi trường, chạy ổn định trong CI / CD, không cần backend và không chứa dữ liệu cá nhân. Result: Why mock the network in E2E tests at all? Tại sao mạng lưới đùa giỡn trong các bài kiểm tra E2E? Mặc dù các bài kiểm tra E2E được thiết kế để kiểm tra ứng dụng "trong tổng thể", trong thực tế bạn hầu như luôn cần phải tách UI khỏi các cuộc gọi mạng thực tế. 1. Test stability Một API thực sự có thể: Không có sẵn Giữ chậm Trả về dữ liệu không thể đoán trước Mocks loại bỏ sự ngẫu nhiên và làm cho các bài kiểm tra có thể lặp lại. 2. Speed Ngay cả với chạy thử nghiệm liên tiếp, phản hồi mock được trả về Không có cuộc gọi mạng thực sự. instantly Điều này làm cho các bài kiểm tra nhanh hơn nhiều lần so với việc đánh vào backend thực sự. 3. Reducing load on the backend Khi các bài kiểm tra E2E chạy song song, chúng tạo ra rất nhiều yêu cầu đồng thời. tạo spikes tải trên máy chủ thử nghiệm, dẫn đến lỗi giới hạn lãi suất, Về cơ bản “DDoS” backend của riêng bạn. Mocks hoàn toàn loại bỏ tải trọng mạng - backend không tham gia thử nghiệm. 4. Independence from external services Stripe, S3, geocoders, OpenAI - bất cứ điều gì có thể thất bại cuối cùng sẽ thất bại. Mocks biến các thử nghiệm E2E thành một lớp hoàn toàn tự trị không phụ thuộc vào API của bên thứ ba. Nhưng có một nhược điểm: nếu một dịch vụ bên ngoài thay đổi hợp đồng của mình hoặc đi xuống, một bài kiểm tra chế giễu sẽ không bao giờ biết và sẽ hạnh phúc vẫn xanh. How Playwright mocks the network Làm thế nào Playwright chế giễu mạng Playwright có một giao diện cấp thấp để chặn và thay thế các yêu cầu: browserContext('**/api/users', route => { route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify(mockUsers), }); }); Bất kỳ yêu cầu nào phù hợp với mô hình (trong ví dụ này, kết thúc với /api/người dùng) sẽ được xử lý cục bộ - mà không cần truy cập Internet, và dữ liệu được chuyển để hoàn thành sẽ được trả về "đối với khách hàng" như là câu trả lời cho yêu cầu này. What is a HAR file and why is it convenient for testing? Tệp HAR là gì và tại sao nó thuận tiện để thử nghiệm? là một file JSON có chứa: HAR (HTTP Archive) Tất cả page yêu cầu Yêu cầu Parameter Server trả lời Nói cách khác, HAR là một bản ghi âm của real network activity. Nếu bạn tạo một HAR một lần (ví dụ, đăng nhập, mở một danh sách, tải một thẻ sản phẩm), sau đó bạn có thể sử dụng tệp này như một nguồn của trò đùa hoàn toàn sao chép hành vi API thực sự. Đó là lý do tại sao HAR là hoàn hảo khi bạn: Cần xác định trạng thái mạng muốn kiểm tra UI mà không cần khởi động backend cần một kịch bản xác định càng gần với thực tế càng tốt How Playwright uses HAR files for mocking Làm thế nào Playwright sử dụng các tập tin HAR để mocking Playwright có thể: kỷ lục đã Replay HAR mà không có cuộc gọi mạng thực Cả hai hoạt động được thực hiện thông qua phương pháp routeFromHAR trên browserContext: browserContext.routeFromHAR(harFilePath, options); 1) Recording HAR browserContext.routeFromHAR(harFilePath, {update: true, url: /api\./}); Playwright tự động chặn tất cả mọi thứ xảy ra trong trình duyệt (trừ khi loại trừ được cấu hình trong tùy chọn) và lưu nó vào *.har file(s) 2) Replaying HAR browserContext.routeFromHAR(harFilePath, {update: false, url: /api\./}); Bây giờ, nếu một thử nghiệm thực hiện một yêu cầu tồn tại trong HAR, Playwright ngay lập tức trả về câu trả lời đã lưu mà không đi đến mạng. Bạn có thể đọc thêm về ghi âm và phát lại HAR trong các tài liệu Playwright. Bạn có thể đọc thêm về ghi âm và phát lại HAR trong Playwright . docs docs Advantages of HAR mocking Lợi ích của HAR Mocking 1.Dữ liệu thực tế HAR chứa các phản hồi máy chủ thực tế, và UI nhìn thấy chúng chính xác như chúng ở thời điểm ghi âm. 2) Độc lập hoàn toàn Không cần máy chủ.Thử nghiệm chạy ngay cả trên máy cục bộ mà không có backend. 3/ Tốc độ cao Phản hồi HAR được trả về ngay lập tức - các bài kiểm tra chạy ở tốc độ tối đa. 4. lý tưởng cho các dòng chảy phức tạp Ví dụ: Authentication Bộ lọc phức tạp Yêu cầu chuỗi Các trang có hàng chục cuộc gọi API Tạo ra những trò đùa như vậy bằng tay là khó khăn, và HAR tự động giải quyết nó. Why HAR mocks can unexpectedly break Tại sao HAR mocks có thể đột ngột phá vỡ Một tập tin HAR được ghi lại là một snapshot của các yêu cầu mạng được thực hiện trong khi nhấn vào backend thực sự trong quá trình thực hiện thử nghiệm. Kết quả là, tập tin có thể chứa dữ liệu động, ID người dùng trong URL và thông tin nhạy cảm (tên mã nguồn, email, v.v.). Trong dự án của chúng tôi, chúng tôi đã gặp 4 vấn đề với dữ liệu trong các tệp HAR: tied to the user under which the HAR was recorded dynamic parts of URLs dynamic request bodies sensitive data that can’t be committed 1.Tied to the user under which the HAR was recorded 1.Thông báo cho người dùng dưới đó HAR đã được ghi lại Trong thực tế, các nhà phát triển đã ghi lại các tập tin HAR trong khi đăng nhập dưới dạng người dùng khác nhau, dẫn đến URL với ID người dùng trở thành một vấn đề ngay lập tức. Example: Trong ứng dụng của chúng tôi, người dùng có thể sử dụng trò chuyện và cũng xem danh sách email nhận được trên một trang riêng biệt. Thử nghiệm cho trang chat sử dụng mocks từ chứa một yêu cầu danh sách người dùng cho một người dùng có ID : chats.har, unique-user-id-1 GET /unique-user-id-1/user/ danh sách Nhận / Người dùng / List unique-user-id-1 { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-1/users/list" } } ] } Tests for the emails page use mocks from Các bài kiểm tra cho các email sử dụng mocks from , cũng chứa một yêu cầu danh sách người dùng, nhưng nó đã được ghi lại dưới một người dùng có ID emails.har unique-user-id-2: GET /unique-user-id-2/user/ danh sách Nhận / Người dùng / List unique-user-id-2 { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-2/users/list" } } ] } hậu quả : Playwright, khi chơi lại, phù hợp với các yêu cầu nghiêm ngặt theo URL, phương pháp và cơ thể, vì vậy ngay cả một sự không phù hợp nhỏ cũng phá vỡ trò đùa. Nếu chúng tôi chạy tất cả các bài kiểm tra đã đăng nhập như người dùng với ID , Playwright sẽ không thể tìm thấy thực thể cần thiết trong khi chạy các bài kiểm tra trang email, bởi vì Endpoint GET đã được ghi lại cho người dùng Trong khi Playwright sẽ tìm kiếm unique-user-id-1 emails.har /unique-user-id-2/users/list unique-user-id-2 /unique-user-id-1/users/list. 2. Dynamic parts of URLs Phần động của URL Example: Tệp HAR có thể chứa một mục nhập với một request-id được tạo ở phía khách hàng: { "entries": [ { "request": { "method": "GET", "url": "/generate?request-id=fc21b48a-e84d-4b-92-a494d65a280a" } } ] } Consequences: sẽ là duy nhất mỗi lần (một giá trị tại thời điểm ghi âm, một giá trị khác tại thời điểm phát lại), vì vậy Playwright sẽ không bao giờ tìm thấy mục này trên các bài kiểm tra tiếp theo, một lần nữa bởi vì Playwright nghiêm ngặt so sánh dữ liệu URL khi tìm kiếm. request-id 3. Dynamic request body Nếu cơ thể chứa các giá trị phải khớp với dữ liệu thu được trong một bước trước (ví dụ, request-id từ /generate), Playwright sẽ chỉ có thể tìm thấy mục HAR chính xác nếu các giá trị này khớp chính xác. Mặc dù các thông số như vậy có tính chất độc đáo, nhưng giá trị của chúng phải giống nhau trên tất cả các yêu cầu liên quan trong thử nghiệm.Nếu ID yêu cầu được chuyển đến /generate không khớp với request_id trong cơ thể yêu cầu tiếp theo, Playwright sẽ không thể tìm thấy một mục phù hợp, và mock sẽ không hoạt động. nơi yêu cầu-id được tạo trước đó được truyền trong cơ thể của một yêu cầu tiếp theo: Example { "entries": [ { "request": { "method": "POST", "url": "/generate-result", "postData": { "text": "{\"request_id\":\"fc21b48a-e84d-4b-92-a494d65a280a\"}" } } } ] } Consequences: Nếu khác với yêu cầu /generate, Playwright sẽ không tìm thấy mục tương ứng trong HAR. request_id 4. Sensitive data that can’t be committed Example: { "entries": [ { "request": { "method": "POST", "url": "api/auth", "postData": { "mimeType": "application/json", "text": "{\"email\":\"test@test.com\",\"password\":\"strongPassword\"}" } } } ] } Consequences: Dữ liệu người dùng thực tế có thể kết thúc trong kho lưu trữ, bởi vì các tập tin HAR phải ở trong repo để chạy thử nghiệm CI / CD. Và hy vọng điểm cuối auth của bạn không chấp nhận dữ liệu như vậy trong văn bản đơn giản trong cuộc sống thực We ended up with these tasks: Chúng tôi kết thúc với những nhiệm vụ này: Các tập tin HAR không được phụ thuộc vào người dùng mà chúng được ghi lại và không được chứa dữ liệu nhạy cảm. Nó không nên quan trọng nơi chúng tôi ghi lại chúng - chúng tôi muốn sử dụng chúng mà không phụ thuộc vào người dùng và dữ liệu của họ. Tệp không được chứa dữ liệu cá nhân thực của người dùng - chỉ có giá trị kiểm tra được kiểm soát. Chúng ta cần dạy các bài kiểm tra của chúng ta làm việc với dữ liệu động Điểm cuối với dữ liệu động phải được tìm thấy trong HAR và chỉ được sử dụng trong thử nghiệm một lần, giống như với các cuộc gọi backend thực sự: một yêu cầu cụ thể - một phản hồi cụ thể. Nếu logic thử nghiệm cần phải gọi một điểm cuối với dữ liệu từ điểm cuối khác, thì phải sử dụng đầu vào HAR tương ứng. How to approach the solution Làm thế nào để tiếp cận giải pháp HAR normalization - một kịch bản riêng biệt mà: finds “original” user data in the HAR and replaces it with test values can normalize previously created HARs so we don’t have to re-record them. Some tests require special conditions for the user in order to reproduce them for recording Dynamic Data Interception (Bắt chặn dữ liệu động) các yêu cầu đến URL có dữ liệu động được chặn lại, và nhập HAR chính xác được trả về trong câu trả lời. HAR normalization Tiêu chuẩn hóa Vì chúng ta cần phải bình thường hóa các HAR được tạo trước đó, nhiệm vụ là tự động phát hiện thông tin người dùng (userId, email, token) và thay thế chúng bằng các giá trị kiểm tra được kiểm soát. Chúng tôi chia quá trình này thành hai bước chính: Trích xuất dữ liệu người dùng thực từ yêu cầu auth, bởi vì đây là nơi duy nhất chúng tôi có thể tìm thấy dữ liệu người dùng chính xác một cách đáng tin cậy: Người dùng Email Token xác thực Dữ liệu nhạy cảm với người dùng với dữ liệu thử nghiệm ở khắp mọi nơi: Walk through all HAR entries and replace Trong tất cả URL In request/response headers (Trang đầu yêu cầu/trả lời) Cơ quan yêu cầu/phản ứng Dưới đây là một phiên bản đơn giản về cách thức bình thường hóa như vậy có thể được thực hiện, đã được chia thành các phần logic. Step 1. Extract user data from HAR Đầu tiên, chúng tôi tìm thấy một yêu cầu auth thành công (/auth với 200 trạng thái) và rút userId, email, và token. interface IdentityData { userId: string email: string token: string } const testData: IdentityData = { userId: '123456789', email: 'test@test.com', token: '936598harmageddoniscancelled5351', }; function extractUserData(harContent: Har): IdentityData | null { const entries = harContent.log.entries; for (const entry of entries) { const url = entry.request?.url || ''; const status = entry.response.status; if (url.includes('/auth') && status === 200) { const responseBody = JSON.parse(entry.response.content.text); const token = entry.response.headers.find( h => h.name.toLowerCase() === 'token' )?.value; return { userId: responseBody.id, email: responseBody.email, token: token, }; } } return null; } Bạn có thể xem loại tập tin HAR chi tiết hơn tại đây: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/har-format/index.d.ts https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/har-format/index.d.ts Step 2. Normalize URLs Tiếp theo, chúng ta cần loại bỏ sự phụ thuộc vào một userId cụ thể trong URL: function normalizeUrl((url: string, identityData: IdentityData, testData: IdentityData): string { // Replace userId – our IDs are unique enough that the chance of // encountering them somewhere else is essentially zero return url.replaceAll(identityData.userId, testData.userId); } Step 3. Normalize headers Tiêu đề thường chứa token và những thứ khác không nên xuất hiện trong kho lưu trữ. function normalizeHeaders(headers: Header[], identityData: IdentityData, testData: IdentityData): Header[] { return headers.map(header => { let value = header.value || ''; // Replace token in the `token` header if (header.name?.toLowerCase() === 'token' && value === identityData.token) { value = testData.token; } return { ...header, value }; }); } Nếu cần thiết, bạn cũng có thể thêm logic thay thế cho Authorization, X-User-Id và các tiêu đề tùy chỉnh khác ở đây. Step 4. Normalize request and response bodies function normalizeContent(text: string, identityData: IdentityData, testData: IdentityData): string { let normalized = text; for (const key of Object.keys(identityData) as (keyof IdentityData)[]) { const original = identityData[key]; const replacement = testData[key]; if (!original || !replacement) continue; normalized = normalized.replaceAll(original, replacement); } return normalized; } Result: putting it all together in normalizeHarFile Kết quả: Đặt tất cả cùng nhau trong normalizeHarFile Bây giờ chúng tôi có tất cả các chức năng trợ lý, bước cuối cùng là đi qua tất cả các mục nhập và áp dụng chuẩn hóa cho tất cả các phần của các yêu cầu / câu trả lời. /** * Normalizes a HAR file by replacing real user data with test data * @param {Har} harContent - HAR file content * @param {Object} testData - test data used for replacement (userId, email, token) */ function normalizeHarFile(harContent: Har, testData: IdentityData) { const entries = harContent.log.entries || []; // 1. Extract real user data from the auth request const identityData = extractUserData(harContent); // 2. Normalize each entry in the HAR file const normalizedEntries = entries.map(entry => { // Normalize request URL if (entry.request.url) { entry.request.url = normalizeUrl( entry.request.url, identityData, testData ); } // Normalize request headers if (entry.request.headers) { entry.request.headers = normalizeHeaders( entry.request.headers, identityData, testData ); } // Normalize response headers if (entry.response.headers) { entry.response.headers = normalizeHeaders( entry.response.headers, identityData, testData ); } // Normalize request body if (entry.request.postData?.text) { entry.request.postData.text = normalizeContent( entry.request.postData.text, identityData, testData ); } // Normalize response body if (entry.response.content.text) { entry.response.content.text = normalizeContent( entry.response.content.text, identityData, testData ); } return entry; }); // 3. Return normalized HAR content harContent.log.entries = normalizedEntries; return harContent; } Dynamic data interception Dynamic Data Interception (Bắt chặn dữ liệu động) Trong hệ thống của chúng tôi, có một số điểm cuối có liên quan: một người nhận được request-id trong các thông số truy vấn (được tạo trên máy khách), và sau đó cùng một request-id phải xuất hiện trong cơ thể của một yêu cầu POST khác. Khi chơi lại HAR, Playwright tương ứng nghiêm ngặt bằng url + phương pháp + cơ thể và không có ý tưởng rằng hai yêu cầu khác nhau được kết nối một cách hợp lý bằng cùng một yêu cầu-id. Sequence of steps Chúng tôi chia công việc với dữ liệu động thành nhiều bước Basic HAR wiring through routeFromHAR Playwright still replays everything it can strictly match. Add a wrapper that: HarMocks Load đã có trong bộ nhớ, có thể tìm kiếm đúng mục nhập có tính đến động lực học (xóa params truy vấn, tìm kiếm trong cơ thể, v.v.) các cửa hàng đã sử dụng yêu cầu-idvalues để tránh tái sử dụng cùng một mục nhập Chặn các URL có vấn đề thông qua context.route: first request: comes in the query request-id (/with-dynamic-request-id) second request: the same is in the body request-id (/with-request-id-inside-body) additional case: static URL + dynamic only in the body ( ) request_id /api/**/with-dynamic-inside-post Mỗi khi Playwright không thể phù hợp với một mục HAR ra khỏi hộp, chúng tôi: Đáp ứng yêu cầu, Tìm đúng mục nhập theo cách thủ công sử dụng nó một lần qua route.fulfill(), Chọn request-id như đã sử dụng. Step 1. Basic HAR setup via routeFromHAR Bước 1: Cài đặt cơ bản HAR thông qua routeFromHAR Hãy bắt đầu với một lớp đơn giản có thể tải HAR và đính kèm nó vào Playwright. async function setupHarMocks(context: BrowserContext, harFileName: string): Promise { const harFilePath = path.join(__dirname, '..', 'har-files', harFileName); if (!fs.existsSync(harFilePath)) { throw new Error(`HAR file not found: ${harFilePath}`); } const harMocks = new HarMocks(context, harFilePath); await harMocks.setupHarMocks(); } export class HarMocks { private context: BrowserContext private harFilePath: string private harContent: HarContent constructor(context: BrowserContext, harFilePath: string) { this.context = context; this.harFilePath = harFilePath; try { this.harContent = JSON.parse(fs.readFileSync(this.harFilePath, 'utf8')); } catch (error) { throw new Error(`Failed to load HAR file ${this.harFilePath}: ${error}`); } } async setupHarMocks(): Promise { await this.context.routeFromHAR(this.harFilePath, { // Use for API requests url: /api\./, // Use only existing entries update: false, }); } } Tại thời điểm này, Playwright đã có thể phát lại HAR, nhưng vẫn còn "chụp" trên các thông số động. . HarMocks Step 2. State for working with dynamic parameters Bước 2: Tình trạng làm việc với các thông số động Chúng ta cần: Store đã sử dụng yêu cầu-id giá trị, nhớ các giá trị request-id được tìm thấy trong một yêu cầu để chúng tôi có thể sử dụng chúng trong một yêu cầu khác. export class HarMocks { private context: BrowserContext private harFilePath: string private harContent: HarContent // In one request the request-id is in query, in another - in body, // so we need to store the found value somewhere private foundSearchParams: Record = {} // Store used request-ids so we don’t reuse the same entry private usedRequestIds: Set = new Set() // ... } Step 3. Helper methods for searching entries in HAR Bước 3: Phương pháp trợ giúp để tìm kiếm các mục trong HAR 3.1. URL normalization (removing dynamic query params) normalize(url: string, removableSearchParams: string[] = []) { const urlObj = new URL(url); removableSearchParams.forEach((param) => { urlObj.searchParams.delete(param) }); return urlObj.toString(); } 3.2. Cache key for found params getKeyForSearchParams(name: string, param: string) { return `${name}_${param}`; } 3.3. Easy access to query params getSearchParams(url: string) { const urlObj = new URL(url); return urlObj.searchParams; } 3.4. Finding HAR entry by URL/method with normalization and an extra check findHarEntry({ requestUrl, method, removableSearchParams = [], customCheck }: { requestUrl: string method: string removableSearchParams?: string[] customCheck?: (entry: HarEntry) => boolean }) { return this.harContent.log.entries.find((entry: HarEntry) => { // Additional check, if provided if (entry.request.method !== method || (customCheck && !customCheck(entry))) { return false; } const normHarUrl = removableSearchParams.length > 0 ? this.normalize(entry.request.url, removableSearchParams) : entry.request.url; if (normHarUrl !== requestUrl) { return false; } return true; }) } 3.5. Finding HAR entry where a parameter is inside the body findHarEntryWithParamsInsideBody({ requestUrl, method, parentParamValue, ownParamName, }: { requestUrl: string method: string parentParamValue: string ownParamName: string }) { if (!parentParamValue) { return false; } return this.harContent.log.entries.find((entry: HarEntry) => { const postDataText = entry.request.postData?.text; if (!postDataText) { return false; } return entry.request.url === requestUrl && entry.request.method === method && postDataText.includes(ownParamName) && postDataText.includes(parentParamValue); }) } 3.6. Extracting request_id from request body extractRequestIdFromPostData(entry: HarEntry): string | null { try { const postDataText = entry.request.postData?.text; if (!postDataText) return null; const postData = JSON.parse(postDataText); return postData.request_id || null; } catch { return null; } } Step 4. Intercepting a request with request-id in query Bước 4: Chặn một yêu cầu với request-id trong truy vấn Điểm cuối đầu tiên: Đến trong query Bản thân Playwright sẽ không tìm thấy mục HAR do so sánh URL nghiêm ngặt, vì vậy chúng tôi làm điều đó cho Playwright. request-id (/with-dynamic-request-id/**) async setupHarMocks(): Promise { await this.context.routeFromHAR(this.harFilePath, { url: /api\./, update: false, }); // URL where request-id is passed in query await this.context.route('**/with-dynamic-request-id/**', async (route) => { const url = route.request().url(); // Remove dynamic request-id from URL const normalizedUrl = this.normalize(url, ['request-id']); const entry = this.findHarEntry({ requestUrl: normalizedUrl, method: 'POST', removableSearchParams: ['request-id'], customCheck: (entry) => { // Ensure request-id from searchParams hasn’t been used yet const searchParams = this.getSearchParams(entry.request.url) const requestId = searchParams.get('request-id') return !requestId || !this.usedRequestIds.has(requestId) }, }); if (!entry) { console.error('Entry not found for:', url); await route.continue(); return; } const searchParams = this.getSearchParams(entry.request.url); const requestId = searchParams.get('request-id'); if (requestId) { // Save request-id for subsequent requests this.foundSearchParams[ this.getKeyForSearchParams('dynamic', 'request-id') ] = requestId; // Mark request-id as used this.usedRequestIds.add(requestId); } await route.fulfill({ status: entry.response.status, headers: entry.response.headers, body: entry.response.content?.text || '{}', }); }) // ...other route handlers } What’s happening here: Chúng tôi chặn yêu cầu bằng mẫu **/with-dynamic-request-id/**. Chúng tôi loại bỏ yêu cầu-id động từ URL để tìm mục phù hợp trong HAR. Thông qua customCheck, chúng tôi đảm bảo rằng request-id này chưa từng được sử dụng trước đây. Chúng tôi lưu request-id trong foundSearchParams và usedRequestIds. Chúng tôi trả về câu trả lời từ HAR thông qua route.fulfill() thay vì nhấn vào backend thực tế. Step 5. Intercepting a request where request-id is in the body Bước 5: Chặn một yêu cầu nơi request-id nằm trong cơ thể Điểm cuối thứ hai nên sử dụng cùng một yêu cầu-id, nhưng lần này bên trong cơ thể yêu cầu như yêu cầu_id : // URL that sends request-id from previous step in the body of a POST request await this.context.route('**/with-request-id-inside-body', async (route) => { const url = route.request().url(); const entry = this.findHarEntryWithParamsInsideBody({ requestUrl: url, method: 'POST', parentParamValue: this.foundSearchParams[ this.getKeyForSearchParams('dynamic', 'request-id') ], ownParamName: 'request_id', }); if (!entry) { console.error('Entry not found for:', url); await route.continue(); return; } await route.fulfill({ status: entry.response.status, headers: entry.response.headers, body: entry.response.content?.text || '{}', }); }) Logic: Chúng tôi lấy yêu cầu-id đã lưu trước đó từ foundSearchParams. Chúng tôi tìm kiếm một mục nhập HAR nơi yêu cầu-id này nằm trong cơ thể dưới phím request_id. Nếu được tìm thấy, chúng tôi trả về mục nhập đó trong bài kiểm tra. Step 6. Static URL + dynamic request_id in the body Bước 6. static URL + dynamic request_id trong cơ thể Một trường hợp bổ sung: URL không thay đổi, nhưng nội dung yêu cầu chứa một , và chúng tôi muốn sử dụng mỗi mục nhập như vậy chỉ một lần. request_id await this.context.route('**/api/**/with-dynamic-inside-post', async (route) => { const url = route.request().url(); const entry = this.findHarEntry({ requestUrl: url, method: 'POST', customCheck: (entry) => { // Ensure request_id from the body hasn’t been used yet const requestId = this.extractRequestIdFromPostData(entry) return !requestId || !this.usedRequestIds.has(requestId) }, }); if (!entry) { console.error('Entry not found for:', url); await route.continue(); return; } const requestId = this.extractRequestIdFromPostData(entry); if (requestId) { this.usedRequestIds.add(requestId); } await route.fulfill({ status: entry.response.status, headers: entry.response.headers, body: entry.response.content?.text || '{}', }); }) Đặt tất cả cùng nhau Để làm cho logic thử nghiệm cư xử giống như với một backend thực sự, chúng ta cần: Hãy để Playwright sử dụng HAR bất cứ nơi nào làm việc phù hợp nghiêm ngặt, Đối với các điểm cuối động, theo dõi yêu cầu theo cách thủ công, bình thường hóa URL và body, chọn đúng mục nhập và đảm bảo mỗi request-id chỉ được sử dụng một lần. Mã trên thực hiện chính xác lớp này trên . routeFromHAR What does Playwright think about this? Playwright nghĩ gì về điều này? Tại thời điểm này, Playwright vẫn là một "chơi HAR đơn giản" mà không có lớp chuẩn hóa: Tương thích nghiêm ngặt theo URL / phương pháp / cơ thể. Không hỗ trợ môi trường chéo/baseURL-aware HAR. Playwright không biết logic miền của bạn. Đó là lý do tại sao các giải pháp riêng biệt xuất hiện trong hệ sinh thái trên Playwright - , , hoặc các giải pháp tùy chỉnh như hoặc . Tác giả: Advanced-har Playwright-network-cache Trò chơi Tải Playwright Network Recordings Chi phí ẩn của Playwright's API mocking (Và giải pháp tùy chỉnh của chúng tôi) Tác giả: Advanced-har Playwright-network-cache Trò chơi Tải Playwright Network Recordings Chi phí ẩn của Playwright's API mocking (Và giải pháp tùy chỉnh của chúng tôi) Conclusion Kết luận Thay vì một loạt các trò đùa mỏng manh, chúng tôi đã kết thúc với một hệ thống thống nhất, trong đó: HAR được ghi lại dưới bất kỳ người dùng nào, Tự động bình thường hóa được sử dụng với dữ liệu hoàn toàn giả, và hoạt động chính xác ngay cả với các thông số động. Cách tiếp cận này đặc biệt hữu ích trong các dự án lớn với nhiều cuộc gọi API và phát triển song song: các thử nghiệm E2E vẫn nhanh, xác định và độc lập với người dùng thực tế. Viết bởi Sergey Levkovich, Nhà phát triển Frontend cao cấp tại Social Discovery Group. Viết bởi Sergey Levkovich, Nhà phát triển Frontend cao cấp tại Social Discovery Group. Viết bởi Senior Frontend Developer tại . Sergey Levkovich Nhóm Social Discovery Sergey Levkovich Sergey Levkovich Nhóm Social Discovery Nhóm Social Discovery