HARmageddon se cancela: cómo enseñamos a Playwright a reproducir HAR con parámetros dinámicos

Los chistes regulares de HAR dejan de funcionar rápidamente: los parámetros dinámicos rompen el ajuste de solicitudes, y el contenido contiene datos sensibles que no se pueden comprometer. Problem: Introducimos la normalización automática de HAR (reemplazo de usuarios, tokens, IDs) y una capa lógica en la parte superior de Playwright que maneja correctamente los parámetros dinámicos. Approach: Enseñamos a Playwright a encontrar la entrada HAR correcta incluso cuando los valores de la consulta / cuerpo cambian y impidimos el reuso de entidades con identificadores dinámicos. What we did: Las pruebas E2E se convirtieron en independientes del medio ambiente, se ejecutan de forma estable en CI/CD, no necesitan el backend y no contienen datos personales. Result: Why mock the network in E2E tests at all? ¿Por qué se burla de la red en las pruebas de E2E? Aunque las pruebas de E2E están destinadas a probar la aplicación "como un todo", en la práctica casi siempre es necesario aislar la interfaz de usuario de las llamadas de red reales. 1. Test stability Un verdadero fuego puede: No estar disponible Ser lenta Devuelve datos impredecibles Elimina la aleatoriedad y hace que las pruebas sean reproducibles. 2. Speed Incluso con las pruebas secuenciales, las respuestas de mock se devuelven Sin llamadas reales a la red. instantly Esto hace que las pruebas sean varias veces más rápidas en comparación con el ataque al backend real. 3. Reducing load on the backend Cuando las pruebas E2E se ejecutan en paralelo, generan una gran cantidad de solicitudes simultáneas. crear picos de carga en el servidor de prueba, los errores de límite de tarifas, Básicamente “DDoS” su propio backend. Mocks elimina completamente la carga de la red - el backend no participa en la prueba en absoluto. 4. Independence from external services Stripe, S3, geocoders, OpenAI - cualquier cosa que pueda fallar finalmente fallará. Mocks convierten las pruebas de E2E en una capa totalmente autónoma que no depende de las APIs de terceros. Pero hay una desventaja: si un servicio externo cambia su contrato o cae, una prueba burlada nunca sabrá y felizmente permanecerá verde. How Playwright mocks the network Cómo Playwright se burla de la red Playwright tiene una interfaz de bajo nivel para interceptar y reemplazar solicitudes: browserContext('**/api/users', route => { route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify(mockUsers), }); }); Cualquier solicitud que coincida con el patrón (en este ejemplo, terminando con /api/usuarios) será tratada localmente - sin ir a Internet, y los datos pasados a cumplimentar serán devueltos "al cliente" como respuesta a esta solicitud. What is a HAR file and why is it convenient for testing? ¿Qué es un archivo HAR y por qué es conveniente para la prueba? Es un archivo JSON que contiene: HAR (HTTP Archive) Todas las solicitudes de página Parámetros de solicitud Respuestas de servidores En otras palabras, es un registro de real network activity. Si usted crea un HAR una vez (por ejemplo, iniciar sesión, abrir una lista, cargar una tarjeta de producto), entonces puede usar este archivo como una fuente de burlas que reproducen completamente el comportamiento de la API real. Es por eso que HAR es perfecto cuando: Necesidad de reparar el estado de la red ¿Quieres probar la UI sin iniciar el backend? Necesitamos un escenario determinista que esté lo más cerca posible de la realidad. How Playwright uses HAR files for mocking Cómo Playwright utiliza archivos HAR para mocking El playwright puede: Record ha Replay HAR sin llamadas de red reales Ambas operaciones se realizan a través del método routeFromHAR en browserContext: browserContext.routeFromHAR(harFilePath, options); 1) Recording HAR browserContext.routeFromHAR(harFilePath, {update: true, url: /api\./}); Playwright intercepta automáticamente todo lo que sucede en el navegador (a menos que se configure las exclusiones en las opciones) y lo guarda en el archivo *.har 2) Replaying HAR browserContext.routeFromHAR(harFilePath, {update: false, url: /api\./}); Ahora, si una prueba hace una solicitud que existe en el HAR, Playwright devuelve inmediatamente la respuesta guardada sin ir a la red. Puede leer más sobre la grabación y la reproducción de HAR en los documentos de Playwright. Puedes leer más sobre grabar y reproducir HAR en el Playwright . docs Docs Advantages of HAR mocking Ventajas del har mocking Datos realistas HAR contiene respuestas reales del servidor, y la interfaz de usuario las ve exactamente como estaban en el momento de la grabación. 2.- El aislamiento total No se necesita ningún servidor. Las pruebas se ejecutan incluso en una máquina local sin un backend. 3 - Alta velocidad Las respuestas HAR se devuelven de inmediato - las pruebas se ejecutan a la velocidad máxima. Ideal para flujos complejos Por ejemplo: Autenticación Filtros complejos Solicitud de cadenas páginas con docenas de llamadas de API Generar tales burlas a mano es difícil, y HAR lo resuelve automáticamente. Why HAR mocks can unexpectedly break Por qué las moscas de HAR pueden romperse inesperadamente Un archivo HAR registrado es una imagen instantánea de las solicitudes de red realizadas mientras se toca el backend real durante la ejecución de la prueba. Como resultado, el archivo puede contener datos dinámicos, ID de usuario en URLs, y información sensible (tokens de autor, correos electrónicos, etc.). En nuestro proyecto encontramos 4 problemas con los datos en los archivos 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.Enviado al usuario bajo el cual se registró el HAR En la práctica, los desarrolladores registraron archivos HAR mientras se conectaban como usuarios diferentes, lo que llevó a que las URL con ID de usuario se convirtieran en un problema inmediatamente. Example: En nuestra aplicación, un usuario puede usar el chat y también ver una lista de correos electrónicos recibidos en una página separada. Testes para la página de chat usando mocks de que contiene una solicitud de lista de usuarios para un usuario con ID : chats.har, unique-user-id-1 GET /unique-user-id-1/usuarios/lista GET /unique-user-id-1/usuarios/lista { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-1/users/list" } } ] } Testes para la página de correos electrónicos que usan mocos de , que también contiene una solicitud de lista de usuarios, pero se registró bajo un usuario con ID emails.har unique-user-id-2: GET /unique-user-id-2/usuarios/lista Obtenga / /Usuarios / Lista unique-user-id-2 { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-2/users/list" } } ] } Las consecuencias: Playwright, cuando se repite, coincide con las solicitudes estrictamente por URL, método y cuerpo, por lo que incluso un pequeño desacuerdo rompe la burla. Si ejecutamos todas las pruebas conectadas como usuario con ID , Playwright no podrá encontrar la entidad necesaria en cuando se ejecutan las pruebas de la página de correo electrónico, porque el punto final GET Fue registrado por el usuario Mientras que Playwright va a buscar 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 Componentes dinámicos de las URL Example: El archivo HAR puede contener una entrada con un ID de solicitud generado en el lado del cliente: { "entries": [ { "request": { "method": "GET", "url": "/generate?request-id=fc21b48a-e84d-4b-92-a494d65a280a" } } ] } Consequences: será único cada vez (un valor en el momento de la grabación, otro en el momento de la reproducción), por lo que Playwright nunca encontrará esta entrada en las pruebas posteriores, otra vez porque Playwright compara estrictamente los datos de URL al buscar. request-id 3. Dynamic request body Si el cuerpo contiene valores que deben coincidir con los datos obtenidos en un paso anterior (por ejemplo, request-id de /generate), Playwright sólo podrá encontrar la entrada HAR correcta si estos valores coinciden exactamente. Aunque tales parámetros son únicos por naturaleza, su valor debe ser el mismo en todas las solicitudes relacionadas en la prueba.Si el ID de solicitud pasado a /generate no coincide con request_id en el cuerpo de la solicitud posterior, Playwright no podrá encontrar una entrada correspondiente, y el engaño simplemente no funcionará. cuando la identificación de solicitud previamente generada se transmite en el cuerpo de una solicitud posterior: Example { "entries": [ { "request": { "method": "POST", "url": "/generate-result", "postData": { "text": "{\"request_id\":\"fc21b48a-e84d-4b-92-a494d65a280a\"}" } } } ] } Consequences: Si diferente de lo que estaba en la solicitud /generate, Playwright no encontrará la entrada correspondiente en el 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: Los datos reales de los usuarios pueden terminar en el repositorio, porque los archivos HAR deben estar en el repo para las pruebas de CI/CD. Y espero que tu punto final auth no acepte tales datos en texto simple en la vida real We ended up with these tasks: Terminamos con estas tareas: Los archivos HAR no deben depender del usuario en el que fueron grabados y no deben contener datos sensibles. No debería importar dónde los hayamos grabado: queremos usarlos sin depender de los usuarios y sus datos. El archivo no debe contener datos personales reales del usuario - sólo valores de prueba controlados. Necesitamos enseñar nuestras pruebas a trabajar con datos dinámicos Los puntos finales con datos dinámicos deben ser encontrados en HAR y utilizados en la prueba sólo una vez, al igual que con las llamadas backend reales: una solicitud específica - una respuesta específica. Si la lógica de prueba necesita llamar a un punto final con datos de otro punto final, debe utilizarse la entrada HAR estrictamente correspondiente. How to approach the solution Cómo acercarse a la solución HAR normalization - un script separado que: 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 Intercepción dinámica de datos Las solicitudes a URLs con datos dinámicos se interceptan y la entrada HAR correcta se devuelve en la respuesta. HAR normalization La normalización Dado que necesitamos normalizar HARs generados previamente, la tarea se reduce a detectar automáticamente las credenciales de usuario (userId, correo electrónico, token) y reemplazarlas con valores de prueba controlados. Dividimos el proceso en dos etapas principales: Extraiga los datos reales de los usuarios de la solicitud auth, porque este es el único lugar donde podemos encontrar de manera fiable los datos correctos de los usuarios: Usuario El email Autenticación Token Datos sensibles al usuario con datos de prueba en todas partes: Walk through all HAR entries and replace En todas las URLs En los encabezados de solicitud/respuesta Los órganos de solicitud/respuesta A continuación se muestra una versión simplificada de cómo se puede implementar tal normalización, ya dividida en partes lógicas. Step 1. Extract user data from HAR Primero, encontramos una solicitud auth exitosa (/auth con estado 200) y extraemos el ID de usuario, correo electrónico y 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; } Puedes ver el tipo de archivo HAR en más detalle aquí: 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 A continuación, necesitamos deshacernos de la dependencia de un usuarioId específico en las 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 Los encabezados a menudo contienen tokens y otras cosas que no deberían aparecer en el repositorio. 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 }; }); } Si es necesario, también puede agregar la lógica de reemplazo para Autorización, X-User-Id y otros encabezados personalizados aquí. 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 Resultado: ponerlo todo juntos en normalizeHarFile Ahora que tenemos todas las funciones de ayudante, el paso final es pasar por todas las entradas y aplicar la normalización a todas las partes de las solicitudes / respuestas. /** * 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 Intercepción dinámica de datos En nuestro sistema, existen varios endpoints relacionados: uno recibe la solicitud-id en los parámetros de la consulta (generados en el cliente), y más tarde la misma solicitud-id debe aparecer en el cuerpo de otra solicitud POST. Al reproducir HAR, Playwright coincide estrictamente por url + método + cuerpo y no tiene idea de que dos solicitudes diferentes estén lógicamente conectadas por el mismo ID de solicitud. Sequence of steps Dividimos el trabajo con datos dinámicos en varias etapas Basic HAR wiring through routeFromHAR Playwright still replays everything it can strictly match. Add a wrapper that: HarMocks cargadas en la memoria, puede buscar la entrada correcta teniendo en cuenta la dinámica (eliminación de parámetros de consulta, búsqueda en el cuerpo, etc.) las tiendas ya usaron los valores de solicitud para evitar reutilizar la misma entrada Intercepta URLs problemáticas a través de 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 Cada vez que Playwright no puede coincidir con una entrada HAR fuera de la caja, nosotros: interceptar la solicitud, encontrar la entrada correcta manualmente, usarlo una vez a través de route.fulfill(), Marque el ID de solicitud como utilizado. Step 1. Basic HAR setup via routeFromHAR Paso 1: Configuración básica de HAR a través de routeFromHAR Comencemos con una clase simple que puede cargar HAR y anexarlo a 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, }); } } En este momento, Playwright ya puede reproducir HAR, pero todavía "se cae" en los parámetros dinámicos. . HarMocks Step 2. State for working with dynamic parameters Paso 2: Estado para trabajar con parámetros dinámicos Nosotros necesitamos: almacenar valores de solicitud-id ya utilizados, Recuerda los valores de solicitud-id encontrados en una solicitud para que podamos usarlos en otra. 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 Paso 3: Métodos de ayuda para buscar entradas en 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 Paso 4: Interceptar una solicitud con request-id en la consulta El primer punto final: Viene a la consulta Playwright no encontrará la entrada HAR debido a la comparación de URL estricta, por lo que lo hacemos para 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: Interceptamos la solicitud por el patrón **/with-dynamic-request-id/**. Eliminamos el ID de solicitud dinámica de la URL para encontrar la entrada correspondiente en HAR. A través de customCheck nos aseguramos de que este identificador de solicitud no haya sido utilizado antes. Guardamos el identificador de solicitud en foundSearchParams y usedRequestIds. Devolvemos la respuesta de HAR a través de route.fulfill() en lugar de golpear el backend real. Step 5. Intercepting a request where request-id is in the body Paso 5: Interceptar una solicitud donde la solicitud-id está en el cuerpo El segundo punto final debe usar el mismo ID de solicitud, pero esta vez dentro del cuerpo de solicitud como Solicitud de identificación: // 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: Tomamos el identificador de solicitud guardado previamente de foundSearchParams. Buscamos una entrada HAR donde esta solicitud-id se encuentra en el cuerpo bajo la clave request_id. Si se encuentra, devolveremos esa entrada en la prueba. Step 6. Static URL + dynamic request_id in the body URL estática + solicitud dinámica_id en el cuerpo Un caso adicional: la URL no cambia, pero el cuerpo de la solicitud contiene un , y queremos utilizar cada entrada sólo una vez. 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 || '{}', }); }) Poniéndolo todo juntos Para que la lógica de prueba se comporte de la misma manera que con un backend real, necesitamos: que el Playwright use HAR dondequiera que funcione una correspondencia estricta, Para los endpoints dinámicos, interceptar solicitudes manualmente, normalizar la URL y el cuerpo, seleccionar la entrada correcta y asegurarse de que cada ID de solicitud se utilice solo una vez. El código de arriba implementa exactamente esta capa en . routeFromHAR What does Playwright think about this? ¿Qué piensa Playwright al respecto? Por el momento, Playwright sigue siendo un “juguete HAR simple” sin capa de normalización: Correspondencia estricta por URL / método / cuerpo. No hay soporte cross-environment/baseURL-aware HAR. Playwright no conoce su lógica de dominio. Es por eso que las soluciones separadas aparecen en el ecosistema en la parte superior de Playwright - , de o soluciones personalizadas como o . Proyecto Avanzado Playwright-network-cache en línea Hackeo de Playwright Network Recordings El costo oculto del mocking de la API de Playwright (y nuestra solución personalizada) Proyecto Avanzado Playwright-network-cache en línea Hackeo de Playwright Network Recordings El costo oculto del mocking de la API de Playwright (y nuestra solución personalizada) Conclusion Conclusión En lugar de un montón de bromas frágiles, acabamos con un sistema unificado donde: Se registra bajo cualquier usuario, se normalizan automáticamente, con datos completamente falsos, y funciona correctamente incluso con parámetros dinámicos. Este enfoque es especialmente útil en proyectos grandes con muchas llamadas de API y desarrollo paralelo: las pruebas de E2E siguen siendo rápidas, deterministas e independientes de los usuarios reales. Escrito por Sergey Levkovich, Senior Frontend Developer en Social Discovery Group. Escrito por Sergey Levkovich, Senior Frontend Developer en Social Discovery Group. Escrito por Senior Frontend Developer en el . Serguéi Levkovich Grupo Discovery Social Serguéi Levkovich Serguéi Levkovich Grupo Discovery Social Grupo Discovery Social