HARmageddon es cancel·la: com vam ensenyar a Playwright a reproduir HAR amb paràmetres dinàmics

Els sorolls HAR regulars deixen de funcionar ràpidament: els paràmetres dinàmics interrompen la coincidència de sol·licituds, i el contingut conté dades sensibles que no es poden comprometre. Problem: Hem introduït la normalització automàtica de HAR (reemplaçament d'usuaris, tokens, ID) i una capa lògica a la part superior de Playwright que gestiona correctament els paràmetres dinàmics. Approach: Hem ensenyat a Playwright a trobar l'entrada HAR correcta fins i tot quan canvien els valors de la consulta / cos i s'evita la reutilització d'entitats amb identificadors dinàmics. What we did: Les proves E2E es van convertir en independents del medi ambient, es van executar de manera estable en CI/CD, no necessiten el backend i no contenen dades personals. Result: Why mock the network in E2E tests at all? Why mock the network in E2E tests at all? Tot i que les proves E2E estan destinades a provar l'aplicació "en el seu conjunt", en la pràctica gairebé sempre cal aïllar la interfície d'usuari de les trucades de xarxa reals. 1. Test stability Un foc real pot: No estar disponible ser lenta Retorn de dades imprevisibles Elimina l'atzar i fa que els tests siguin reproduïbles. 2. Speed Fins i tot amb les proves seqüencials, es tornen les respostes de mock Sense trucades reals de xarxa. instantly Això fa que les proves siguin diverses vegades més ràpides en comparació amb colpejar el backend real. 3. Reducing load on the backend Quan les proves E2E s'executen en paral·lel, generen moltes sol·licituds simultànies. crear pics de càrrega en el servidor de proves, condueix a errors de tipus límit, Bàsicament “DDoS” el seu propi backend. Mocks elimina completament la càrrega de la xarxa - el backend no participa en la prova en absolut. 4. Independence from external services Stripe, S3, geocoders, OpenAI - qualsevol cosa que pugui fallar acabarà fallant. Mocks converteix les proves E2E en una capa totalment autònoma que no depèn de les APIs de tercers. Però hi ha un inconvenient: si un servei extern canvia el seu contracte o cau, una prova ridícula mai no ho sabrà i quedarà feliçment verda. How Playwright mocks the network Com Playwright es burla de la xarxa Playwright té una interfície de baix nivell per interceptar i substituir sol·licituds: browserContext('**/api/users', route => { route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify(mockUsers), }); }); Qualsevol sol·licitud que coincideixi amb el patró (en aquest exemple, que acaba amb /api/usuaris) es processarà localment - sense anar a Internet, i les dades passades a complir seran retornades "al client" com a resposta a aquesta sol·licitud. What is a HAR file and why is it convenient for testing? Què és un arxiu HAR i per què és convenient per a la prova? És un arxiu JSON que conté: HAR (HTTP Archive) Totes les pàgines sol·licitades Sol·licitud de paràmetres Serveis de resposta En aquest sentit, és un registre de real network activity. Si crea un HAR una vegada (per exemple, iniciar sessió, obrir una llista, carregar una targeta de producte), llavors pot utilitzar aquest fitxer com una font de ridícules que reprodueixen completament el comportament de l'API real. És per això que HAR és perfecte quan: Cal fixar l'estat de la xarxa Vull provar la interfície sense iniciar el backend Necessitem un escenari determinista que sigui el més proper possible a la realitat. How Playwright uses HAR files for mocking Com Playwright utilitza arxius HAR per mocking El playwright pot: El record ha Replay HAR sense trucades de xarxa real Both operations are done via the routeFromHAR method on browserContext: browserContext.routeFromHAR(harFilePath, options); 1) Recording HAR browserContext.routeFromHAR(harFilePath, {update: true, url: /api\./}); Playwright intercepta automàticament tot el que succeeix al navegador (a menys que s'hagin configurat les exclusions a les opcions) i l'emmagatzema en el fitxer *.har. 2) Replaying HAR browserContext.routeFromHAR(harFilePath, {update: false, url: /api\./}); Ara, si un test fa una sol·licitud que existeix en el HAR, Playwright retornarà immediatament la resposta guardada sense anar a la xarxa. Podeu llegir més sobre la gravació i la reproducció de HAR en els documents de Playwright. Podeu llegir més sobre gravar i reproduir HAR en el Playwright . Docs Docs Advantages of HAR mocking Avantatges del HAR mocking Dades realistes HAR conté respostes reals del servidor, i la interfície d'usuari les veu exactament com eren en el moment de la gravació. 2 Isolament total No es necessita cap servidor. Les proves s'executen fins i tot en una màquina local sense un backend. 3 - Alta velocitat Les respostes HAR es tornen instantàniament - les proves s'executen a la velocitat màxima. Ideal per a fluxos complexos Per exemple: authentication Filtres complexos Sol·licitud de cadenes pages with dozens of API calls La generació d'aquestes bromes per mà és difícil, i HAR ho resol automàticament. Why HAR mocks can unexpectedly break Per què les mosques de HAR poden trencar inesperadament Un arxiu HAR enregistrat és una imatge instantània de les sol·licituds de xarxa realitzades mentre es colpeja el backend real durant l'execució de la prova. com a resultat, el fitxer pot contenir dades dinàmiques, identificadors d'usuari en URLs i informació sensible (tokens d'autorització, correus electrònics, etc.). En el nostre projecte vam trobar 4 problemes amb les dades en arxius 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 Enviat a l'usuari sota el qual s'ha registrat l'HAR En la pràctica, els desenvolupadors van gravar els arxius HAR mentre s'havien iniciat com a usuaris diferents, cosa que va fer que les URL amb ID d'usuari esdevinguessin immediatament un problema. Example: En la nostra aplicació, un usuari pot utilitzar el xat i també veure una llista de correus electrònics rebuts en una pàgina separada. Tests per a la pàgina de xat utilitzar mocks de que conté una sol·licitud de llista d'usuaris per a un usuari amb ID : chats.har, unique-user-id-1 GET /unique-user-id-1/users/llista dels usuaris GET /unique-user-id-1/users/llista dels usuaris { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-1/users/list" } } ] } Tests per a les pàgines de correus electrònics utilitzen mocks de , que també conté una sol·licitud de llista d'usuaris, però es va gravar sota un usuari amb ID emails.har unique-user-id-2: GET /unique-user-id-2/users/llista dels usuaris Obtenir / Usuaris / Llista unique-user-id-2 { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-2/users/list" } } ] } Les conseqüències: Playwright, quan es reprodueix, coincideix sol·licituds estrictament per URL, mètode i cos, de manera que fins i tot una petita discrepància trenca la broma. Si executem totes les proves connectades com a usuari amb ID , Playwright no podrà trobar l'entitat necessària en when running the email page tests, because the endpoint GET Va ser gravat per l'usuari Mentre que Playwright 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 Parts dinàmiques d'URL Example: El fitxer HAR pot contenir una entrada amb un request-id generat al costat del client: { "entries": [ { "request": { "method": "GET", "url": "/generate?request-id=fc21b48a-e84d-4b-92-a494d65a280a" } } ] } Consequences: serà únic cada vegada (un valor en el moment de la gravació, un altre en el moment de la reproducció), de manera que Playwright mai trobarà aquesta entrada en les proves posteriors, de nou perquè Playwright compara estrictament les dades d'URL quan cerca. request-id 3. Dynamic request body Si el cos conté valors que han de coincidir amb les dades obtingudes en un pas anterior (per exemple, request-id de /generate), Playwright només podrà trobar l'entrada HAR correcta si aquests valors coincideixen exactament. Tot i que aquests paràmetres són únics per la seva naturalesa, el seu valor ha de ser el mateix per a totes les sol·licituds relacionades en el test. Si la identificació de sol·licitud passada a /generate no coincideix amb la request_id en el cos de la sol·licitud posterior, Playwright no podrà trobar una entrada corresponent, i el mock simplement no funcionarà. Quan l'identificador de sol·licitud anteriorment generat es transmet en el cos d'una sol·licitud posterior: Example { "entries": [ { "request": { "method": "POST", "url": "/generate-result", "postData": { "text": "{\"request_id\":\"fc21b48a-e84d-4b-92-a494d65a280a\"}" } } } ] } Consequences: Si diferent del que es trobava a la sol·licitud /generate, Playwright no trobarà l'entrada corresponent a l'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: Les dades d'usuari reals poden acabar en el repositori, ja que els arxius HAR han d'estar en el repo per a les proves de CI/CD. And hopefully your auth endpoint doesn’t accept such data in plain text in real life We ended up with these tasks: Hem acabat amb aquestes tasques: Els arxius HAR no han de dependre de l'usuari en què van ser gravats i no han de contenir dades sensibles. It shouldn’t matter where we recorded them - we want to use them without depending on users and their data. Every test should run with the same test credentials. El fitxer no ha de contenir dades personals reals de l'usuari - només valors de prova controlats. Hem d'ensenyar les nostres proves a treballar amb dades dinàmiques Endpoints with dynamic data must be found in HAR and used in the test only once, just like with real backend calls: a specific request - a specific response. If test logic needs to call an endpoint with data from another endpoint, the strictly corresponding HAR entry must be used. How to approach the solution Com apropar-se a la solució HAR normalization - a separate script that: 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ó de dades dinàmica Les sol·licituds d'URL amb dades dinàmiques són interceptades i la entrada HAR correcta es retorna en la resposta. HAR normalization La normalització Atès que hem de normalitzar els HARs generats anteriorment, la tasca es redueix a detectar automàticament les credencials d'usuari (userId, correu electrònic, token) i reemplaçar-les amb valors de prova controlats. Hem dividit el procés en dues etapes principals: Extraure dades d'usuari reals de la sol·licitud auth, perquè aquest és l'únic lloc on podem trobar de manera fiable les dades d'usuari correctes: Usuaris El correu Autenticació token Dades sensibles a l'usuari amb dades de prova a tot arreu: Walk through all HAR entries and replace En tots els URL En capçalera de petició/resposta En els òrgans de petició/resposta A continuació es mostra una versió simplificada de com es pot implementar aquesta normalització, ja dividida en parts lògiques. Step 1. Extract user data from HAR First, we find a successful auth request (/auth with 200 status) and pull out userId, email, and token. These data will be the “originals” we’ll replace. 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; } Podeu veure el tipus de fitxer HAR en més detall 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ó, hem de desfer-nos de la dependència d'un usuari específic en les 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 Els encapçalaments sovint contenen tokens i altres coses que no haurien d'aparèixer en el repositori. 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 és necessari, també podeu afegir lògica de reemplaçament per a Autorització, X-User-Id i altres encapçalaments personalitzats 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 El resultat: posar-ho tot junts en normalitzarHarFile Ara que tenim totes les funcions d'ajuda, l'últim pas és anar a través de totes les entrades i aplicar la normalització a totes les parts de les sol·licituds / respostes. /** * 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ó de dades dinàmica En el nostre sistema, hi ha diversos endpoints relacionats: un rep request-id en paràmetres de consulta (generat en el client), i més tard el mateix request-id ha d'aparèixer en el cos d'una altra sol·licitud POST. When replaying HAR, Playwright strictly matches by url + method + body and has no idea that two different requests are logically connected by the same request-id. So we had to add our own layer on top of routeFromHAR. Sequence of steps We split the work with dynamic data into several steps Basic HAR wiring through routeFromHAR Playwright still replays everything it can strictly match. Add a wrapper that: HarMocks carregades en la memòria, pot cercar l'entrada correcta tenint en compte la dinàmica (eliminar params de consulta, cercar en el cos, etc.) stores already used values to avoid reusing the same entry request-id Interceptar URLs problemàtiques 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 vegada que Playwright no pot coincidir amb una entrada HAR fora de la caixa, nosaltres: interceptar la sol·licitud, trobar l'entrada correcta manualment, utilitzeu-lo una vegada a través de route.fulfill(), mark the as used. request-id Step 1. Basic HAR setup via routeFromHAR Etapa 1: Configuració bàsica de HAR a través de routeFromHAR Let’s start with a simple class that can load HAR and attach it to 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 aquest punt, Playwright ja pot reproduir HAR, però encara "caiguda" en paràmetres dinàmics. . HarMocks Step 2. State for working with dynamic parameters Pas 2: Estat per treballar amb paràmetres dinàmics Necessitem que: emmagatzema ja utilitzats els valors de sol·licitud-id, Recordeu els valors de request-id que es troben en una sol·licitud perquè puguem utilitzar-los en una altra. 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 Pas 3: Mètodes d'ajuda per a la cerca d'entrades 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 Pas 4: Interceptar una sol·licitud amb request-id a la consulta El primer punt final: Vine a la consulta Playwright no trobarà l'entrada HAR a causa de la comparació d'URL estricta, de manera que ho fem per 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: Interceptem la sol·licitud mitjançant el patró **/with-dynamic-request-id/**. Eliminem la identificació de sol·licitud dinàmica de l'URL per trobar l'entrada corresponent a HAR. A través de customCheck ens assegurem que aquesta identificació de sol·licitud no s'hagi utilitzat abans. Guardem l'id de sol·licitud a foundSearchParams i usatRequestIds. We return the response from HAR via instead of hitting the real backend. route.fulfill() Step 5. Intercepting a request where request-id is in the body Pas 5: Interceptació d'una sol·licitud on el request-id es troba en el cos El segon punt final ha d'utilitzar la mateixa identificació de sol·licitud, però aquesta vegada dins del cos de la sol·licitud com Sol·licitud 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: Prenem l'identificador de sol·licitud guardat anteriorment de foundSearchParams. Busquem una entrada HAR on aquesta sol·licitud-id es troba al cos sota la clau request_id. Si es troba, retornem aquesta entrada a la prova. Step 6. Static URL + dynamic request_id in the body URL estàtica + request_id dinàmic en el cos An additional case: the URL doesn’t change, but the request body contains a unique , i volem utilitzar cada entrada només una vegada. 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 || '{}', }); }) Posant-ho tot plegat Per fer que la lògica de la prova es comporti de la mateixa manera que amb un backend real, necessitem: Que el Playwright utilitzi HAR allà on hi hagi treballs d'ajust estricte, Per a endpoints dinàmics, interceptar sol·licituds manualment, normalitzar la URL i el cos, seleccionar l'entrada correcta i assegurar-se que cada identificador de sol·licitud s'utilitzi només una vegada. El codi anterior implementa exactament aquesta capa a la part superior de . routeFromHAR What does Playwright think about this? Què en pensa Playwright? Actualment, Playwright segueix sent un "jocador HAR simple" sense cap capa de normalització: Correspondència estricta per URL / mètode / cos. No cross-environment/baseURL-aware HAR support. Playwright no coneix la teva lògica de domini. És per això que apareixen solucions separades en l'ecosistema a la part superior de Playwright - , o solucions customitzades com o . Espectacle d'avantguarda Playwright-network-cache en línia Hacking Playwright Network Recordings El cost ocult del mocking de l'API de Playwright (i la nostra solució personalitzada) Espectacle d'avantguarda Playwright-network-cache en línia Hacking Playwright Network Recordings El cost ocult del mocking de l'API de Playwright (i la nostra solució personalitzada) Conclusion Conclusion Instead of a bunch of fragile mocks, we ended up with a unified system where: S'ha registrat sota qualsevol usuari, normalitzat automàticament utilitzat amb dades completament falses, i funciona correctament fins i tot amb paràmetres dinàmics. Aquest enfocament és especialment útil en grans projectes amb moltes trucades d'API i desenvolupament paral·lel: les proves E2E es mantenen ràpides, deterministes i independents dels usuaris reals. Escrit per Sergey Levkovich, Senior Frontend Developer de Social Discovery Group. Escrit per Sergey Levkovich, Senior Frontend Developer de Social Discovery Group. Escrit per Senior Frontend Developer en . Sergey Levkovich Social Discovery Group Sergi Levkovic Sergi Levkovic Grup de descobriment social Grup de descobriment social