HARmageddon е откажан: како го научивме Playwright да го репродуцира HAR со динамички параметри

Редовните HAR шеги брзо престануваат да работат - динамичките параметри го прекинуваат усогласувањето на барањето, а содржината содржи чувствителни податоци кои не можат да се ангажираат. Problem: Воведевме автоматска HAR нормализација (замена на корисници, токени, ID) и логички слој на врвот на Playwright кој правилно ги обработува динамичките параметри. Approach: Ние го научивме Playwright да го најде вистинскиот HAR влез дури и кога вредностите на прашањето / телото се менуваат и спречи повторно користење на ентитети со динамички идентификатори. What we did: E2E тестовите станаа независни од животната средина, работат стабилно во CI / CD, не им е потребен резервен крај и не содржат лични податоци. Result: Why mock the network in E2E tests at all? Зошто се шегуваат на мрежата во E2E тестови воопшто? Иако E2E тестовите се наменети за тестирање на апликацијата "како целина", во пракса, речиси секогаш треба да го изолирате интерфејсот на корисникот од вистинските повици на мрежата. 1. Test stability Вистинскиот огномет може: Бидете недостижни Бидете бавни Враќање на непредвидливи податоци Моките ја елиминираат случајноста и ги прават тестовите репродуктивни. 2. Speed Дури и со последователни тестови, одговорите се враќаат Без вистински телефонски повици. instantly Ова ги прави тестовите неколку пати побрзи во споредба со погодувањето на вистинскиот задник. 3. Reducing load on the backend Кога E2E тестовите се изведуваат паралелно, тие генерираат многу истовремени барања. креирање на врвови на товарот на серверот за тестирање, доведува до грешки во стапката на лимит, Во суштина “DDoS” вашиот сопствен backend. Моцки целосно го отстрануваат оптоварувањето на мрежата - резервниот крај воопшто не учествува во тестот. 4. Independence from external services Stripe, S3, геокодери, OpenAI - сè што може да пропадне на крајот ќе пропадне. Mocks ги претвора тестовите на E2E во целосно автономно ниво кое не зависи од API-то на трети страни. Но, постои недостаток: ако надворешна услуга го менува својот договор или паѓа, исмејаниот тест никогаш нема да знае и со задоволство ќе остане зелен. How Playwright mocks the network Како Playwright се потсмева на мрежата Playwright има интерфејс на ниско ниво за пресретнување и замена на барања: browserContext('**/api/users', route => { route.fulfill({ status: 200, contentType: 'application/json', body: JSON.stringify(mockUsers), }); }); Секое барање што одговара на шаблонот (во овој пример, завршувајќи со /api/потребители) ќе се обработува локално - без да оди на интернет, а податоците пренесени за исполнување ќе бидат вратени „на клиентот“ како одговор на ова барање. What is a HAR file and why is it convenient for testing? Што е HAR датотека и зошто е погодна за тестирање? е JSON датотека која содржи: HAR (HTTP Archive) Сите страници барања Барање на параметри Серверски одговори Со други зборови, HAR е запис на real network activity. Ако создадете HAR еднаш (на пример, да се најавите, да отворите листа, да наполните картичка со производ), тогаш можете да го користите овој датотека како извор на шеги кои целосно го репродуцираат вистинското однесување на API. Ова е причината зошто HAR е совршен кога: Потребно е да се поправи мрежната состојба сакате да го тестирате UI без да го започнете backend Потребен е детерминистички сценарио што е што е можно поблиску до реалноста How Playwright uses HAR files for mocking Како Playwright користи HAR датотеки за подигање Playwright може да: Рекордот е Повторно репродукција на HAR без вистински мрежни повици И двете операции се изведуваат преку методот routeFromHAR на browserContext: browserContext.routeFromHAR(harFilePath, options); 1) Recording HAR browserContext.routeFromHAR(harFilePath, {update: true, url: /api\./}); Playwright автоматски пресретнува сè што се случува во прелистувачот (освен ако исклучоците не се конфигурирани во опциите) и го зачувува во *.har датотеката(и) 2) Replaying HAR browserContext.routeFromHAR(harFilePath, {update: false, url: /api\./}); Сега, ако тест прави барање кое постои во HAR, Playwright веднаш го враќа зачуваниот одговор без да оди во мрежата. Можете да прочитате повеќе за снимање и репродукција на HAR во Playwright документи. Можете да прочитате повеќе за снимање и репродукција на HAR во Playwright . Доц Доц Advantages of HAR mocking Предности на HAR Mocking Реалистички податоци HAR содржи вистински сервери одговори, и интерфејсот на корисникот ги гледа токму како што беа во моментот на снимање. Потполна изолација Не е потребен сервер. Тестовите се изведуваат дури и на локална машина без резервен крај. 3. високи брзини HAR одговорите се враќаат веднаш - тестовите се изведуваат со максимална брзина. Идеален за комплексни текови На пример: аутентификација Комплексни филтри Барање за синџири Страници со десетици API повици Генерирање на такви шеги со рака е тешко, и HAR го решава тоа автоматски. Why HAR mocks can unexpectedly break Зошто HAR шегите можат неочекувано да се скршат Запишаната HAR датотека е снимање на мрежните барања направени додека го погоди вистинскиот резервен крај за време на извршувањето на тестот. Како резултат на тоа, датотеката може да содржи динамички податоци, кориснички ИД во URL адреси и чувствителни информации (аут токени, е-пошта итн.). Во нашиот проект наидовме на 4 проблеми со податоците во 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.Донесено до корисникот под кој е снимен HAR Во пракса, програмерите ги снимале HAR датотеките додека биле најавени како различни корисници, што довело до тоа што URL-то со кориснички ID-и веднаш станало проблем. Example: Во нашата апликација, корисникот може да користи разговор и исто така да ја прегледа листата на примени пораки на посебна страница. Тестови за страницата за разговор користете мустаќи од која содржи барање за корисничка листа за корисник со ИД : chats.har, unique-user-id-1 GET /unique-user-id-1 / корисници / листа Добијте Корисници / Листа unique-user-id-1 { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-1/users/list" } } ] } Тестови за страниците за е-пошта користат шеги од , кој исто така содржи барање за корисничка листа, но беше запишано под корисник со ИД emails.har unique-user-id-2: GET /unique-user-id-2 / корисници / листа GET /unique-user-id-2 / корисници / листа { "entries": [ { "request": { "method": "GET", "url": "/unique-user-id-2/users/list" } } ] } Последици од: Плејворт, кога се репродуцира, ги совпаѓа барањата строго по URL, метод и тело, така што дури и мал несогласување го крши измамата. Ако ги извршиме сите тестови најавени како корисник со ID , Playwright нема да може да го најде потребниот ентитет во при извршување на тестовите за е-пошта, бидејќи крајната точка го добива Запишано за корисникот Додека Playwright ќе бара 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 Динамички делови на URL-то Example: HAR датотеката може да содржи запис со request-id генериран од страна на клиентот: { "entries": [ { "request": { "method": "GET", "url": "/generate?request-id=fc21b48a-e84d-4b-92-a494d65a280a" } } ] } Consequences: ќе биде уникатен секој пат (една вредност во време на снимање, друга во време на репродукција), така што Playwright никогаш нема да ја најде оваа статија на последователни тестови, повторно затоа што Playwright строго ги споредува податоците за URL при пребарување. request-id 3. Dynamic request body Ако телото содржи вредности кои мора да одговараат на податоците добиени во претходниот чекор (на пример, request-id од /generate), Playwright ќе може да го најде вистинскиот HAR влез само ако овие вредности точно се совпаѓаат. Иако таквите параметри се уникатни по природа, нивната вредност мора да биде иста за сите поврзани барања во тестот.Ако идентитетот на барањето пренесен на /generate не одговара на request_id во следното тело на барањето, Playwright нема да може да најде соодветна статија, а измамата едноставно нема да работи. каде што претходно генерираното барање-идентификатор се пренесува во телото на подоцнежно барање: Example { "entries": [ { "request": { "method": "POST", "url": "/generate-result", "postData": { "text": "{\"request_id\":\"fc21b48a-e84d-4b-92-a494d65a280a\"}" } } } ] } Consequences: Ако се разликува од она што беше во /генерира барање, Playwright нема да го најде соодветниот влез во 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: Реалните кориснички податоци може да завршат во репозиториумот, бидејќи HAR датотеките мора да бидат во репо за CI/CD тестови. И се надевам дека вашата auth крајна точка не прифаќа такви податоци во обичен текст во реалниот живот We ended up with these tasks: Завршивме со овие задачи: HAR датотеките не смеат да зависат од корисникот под кој биле снимени и не смеат да содржат чувствителни податоци. Не треба да е важно каде ги снимаме - сакаме да ги користиме без да зависиме од корисниците и нивните податоци. Датотеката не смее да содржи вистински лични кориснички податоци - само контролирани тест вредности. Треба да ги научиме нашите тестови да работат со динамички податоци Крајните точки со динамички податоци мора да се пронајдат во HAR и да се користат во тестот само еднаш, исто како и со вистински бак-енд повици: специфично барање - специфичен одговор. Ако тестовата логика треба да повика крајна точка со податоци од друга крајна точка, мора да се користи строго соодветниот HAR влез. How to approach the solution Како да се приближите до решението HAR нормализација - посебен скрипт кој: 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 Динамична пресретнување на податоци Барањата за URL-адреси со динамички податоци се пресретнуваат, а во одговорот се враќа точниот HAR-запис. HAR normalization Постои нормализација Бидејќи треба да ги нормализираме претходно генерираните HARs, задачата доаѓа до автоматско откривање на корисничките верификации (userId, e-mail, token) и заменување со контролирани тестови. Процесот го поделивме во две главни фази: Извадете вистински кориснички податоци од аутх барањето, бидејќи ова е единственото место каде што можеме да ги најдеме точните кориснички податоци: Корисникот Е-мејл Токен за автентичност кориснички чувствителни податоци со податоци за тестирање насекаде: Walk through all HAR entries and replace Во сите URL-и Во главите на барањето / одговорот Органи за барање/одговор Подолу е поедноставена верзија на тоа како таквата нормализација може да се имплементира, веќе поделена на логички делови. Step 1. Extract user data from HAR Прво, ние ќе најдеме успешна auth барање (/auth со 200 статус) и извади userId, e-mail, и токен. 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; } Можете да го видите типот на датотеката HAR во повеќе детали тука: 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 Следно, треба да се ослободиме од зависноста од одредена userId во 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 Заглавките често содржат токени и други работи кои не треба да се појавуваат во репозиториумот. 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 }; }); } Ако е потребно, можете исто така да додадете логика за замена за овластување, X-User-Id и други кориснички наслови тука. 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 Резултат: ставање на сето тоа заедно во normalizeHarFile Сега што ги имаме сите функции на помошник, последниот чекор е да се оди низ сите записи и да се примени нормализација на сите делови на барањата / одговорите. /** * 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 Динамична пресретнување на податоци Во нашиот систем, постојат неколку поврзани крајни точки: еден добива request-id во параметрите на прашањето (генерирани на клиентот), а подоцна истиот request-id мора да се појави во телото на друго POST барање. Кога го репродуцира HAR, Playwright строго се совпаѓа со url + метод + тело и нема поим дека две различни барања се логички поврзани со истиот request-id. Sequence of steps Ние ја поделивме работата со динамички податоци во неколку чекори Basic HAR wiring through routeFromHAR Playwright still replays everything it can strictly match. Add a wrapper that: HarMocks и во сеќавањата се вклопуваат, може да пребарувате за точниот влез земајќи ги предвид динамиките (да ги отстраните парамите на прашањето, да пребарувате во телото итн.) продавници веќе користеле барања-ид-вредности за да се избегне повторна употреба на истиот влез Прекинување на проблематични URL-адреси преку 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 Секој пат кога Playwright не може да се совпадне со HAR влез надвор од кутијата, ние: прифаќање на барањето, пронајдете го вистинскиот влез рачно, користете го еднаш преку route.fulfill(), Означете го барањето-иД како што се користи. Step 1. Basic HAR setup via routeFromHAR Чекор 1: Основно поставување на HAR преку routeFromHAR Да почнеме со едноставна класа која може да ја вчита HAR и да ја прикачи на 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, }); } } Во овој момент, Playwright веќе може да го репродуцира HAR, но сепак "престанува" на динамички параметри. . HarMocks Step 2. State for working with dynamic parameters Чекор 2: состојба за работа со динамички параметри Ние треба да: складирање веќе користени барања-ид вредности, запомнете барања-ид вредности пронајдени во една барање за да можеме да ги користиме во друга. 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 Чекор 3: Помош методи за пребарување на записи во 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 Чекор 4: Преземање на барање со request-id во прашање Првата крајна точка: Доаѓа во пребарувањето Самиот Playwright нема да го најде влезот HAR поради строгото споредување на URL-то, па го правиме тоа за 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: Ние го пресретнуваме барањето со образец **/with-dynamic-request-id/**. Ние го отстрануваме динамичкиот идентификатор на барање од URL-то за да го најдеме соодветниот запис во HAR. Преку customCheck ние гарантираме дека овој request-id не е користен порано. Ние го зачувуваме идентитетот на барањето во foundSearchParams и usedRequestIds. Ние го враќаме одговорот од HAR преку route.fulfill() наместо да го погодиме вистинскиот крај. Step 5. Intercepting a request where request-id is in the body Чекор 5: Преземање на барање каде што request-id е во телото Втората крајна точка треба да го користи истиот request-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: Ние го земаме претходно зачуваниот request-id од foundSearchParams. Ние бараме HAR запис каде што ова барање-id е во телото под request_id клуч. Ако се најде, ние го враќаме тој влез во тестот. Step 6. Static URL + dynamic request_id in the body Статички URL + динамички request_id во телото Дополнителен случај: URL-то не се менува, но телото на барањето содржи , и сакаме да го користиме секој таков влез само еднаш. 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 || '{}', }); }) Да го ставиме сето тоа заедно За да се направи тест логика се однесуваат на ист начин како и со вистински задната страна, ние треба да: нека Playwright го користи HAR каде и да работи строго совпаѓање, за динамички крајни точки, рачно пресретнувајте барања, нормализирајте ги URL-то и телото, изберете го вистинскиот влез и осигурајте се дека секој идентификатор на барање се користи само еднаш. Кодот погоре го имплементира токму овој слој на . routeFromHAR What does Playwright think about this? Што мисли Playwright за ова? Во моментов, Playwright останува „једноставен HAR играч“ без слој на нормализација: Строго совпаѓање по URL / метод / тело. Нема cross-environment/baseURL-aware HAR поддршка. Playwright не ја знае вашата логика на домен. Тоа е зошто одделни решенија се појавуваат во екосистемот на врвот на Playwright - , на или прилагодливи решенија како или . Напредно-напредно играње играч-мрежата-каша Hacking Playwright Network Recordings The Hidden Cost of Playwright’s API Mocking (And Our Custom Solution) Напредно-напредно играње играч-мрежата-каша Хакирање на Playwright Network Recordings Скриената цена на глумењето на Плејвортот (и нашето прилагодено решение) Conclusion Заклучок Наместо еден куп кршливи шеги, завршивме со единствен систем каде: е запишана под секој корисник, автоматски се нормализира, користени со целосно лажни податоци, и работи правилно дури и со динамички параметри. Овој пристап е особено корисен во големи проекти со многу API повици и паралелен развој: тестовите на E2E остануваат брзи, детерминистички и независни од вистинските корисници. Напишано од Сергеј Левковиќ, старши Frontend Developer на Social Discovery Group. Напишано од Сергеј Левковиќ, старши Frontend Developer на Social Discovery Group. Напишано од Старши фронтен девелопер на . Сергеј Левковиќ Social Discovery Group Сергеј Левковиќ Сергеј Левковиќ Група за социјално откривање Група за социјално откривање