Source
QA Co-pilot | ️ Битва підходів: Junior vs. QA Architect (Цикли проти Нативних ассерт...
24 Views/Reach
2026-05-25 13:28
Message №305
⚔️ Битва підходів: Junior vs. QA Architect (Цикли проти Нативних ассертів)Сьогодні розберемо класичну ситуацію: вам треба перевірити масив елементів на сторінці (наприклад, список повідомлень у чаті або таблицю). Як витягнути та перевірити дані, не змусивши ваш тест "гальмувати"? ☕️❌ Підхід Junior-автоматизатораconst texts = [];const messages = page.locator('.chat-message');const count = await messages.count();for (let i = 0; i < count; i++) { // Повільно витягуємо текст по одному... texts.push(await messages.nth(i).textContent());}expect(texts).toContain('Замовлення успішне');
Чому це антипатерн: Це повільно і крихко. По-перше, count() стріляє миттєво і не чекає на рендер (часто повертає 0). По-друге, кожна ітерація циклу for робить окремий асинхронний запит до браузера. Якщо у чаті 50 повідомлень — тест гарантовано "зависне" на кілька секунд.✅ Підхід QA Architect// Варіант 1: Одразу перевіряємо наявність тексту у списку (з auto-retry)await expect(page.locator('.chat-message')).toContainText(['Замовлення успішне']);// Варіант 2: Якщо масив реально потрібен для хитрої логікиconst allTexts = await page.locator('.chat-message').allTextContents();
Чому це шедевр: Швидкість світла і стабільність. Playwright виконує allTextContents() або toContainText() за одну мілісекунду на рівні браузерного рушія, перехоплюючи весь масив одразу. Крім того, веб-ассерт автоматично зачекає (до 5 секунд), поки потрібне повідомлення не з'явиться в DOM, що рятує від Flaky-тестів.Золоте правило: Якщо ви пишете цикл for для перебору UI-елементів у Playwright — зупиніться. З імовірністю 99% ви робите щось не так і для цього вже є нативний оптимізований метод.А як ви працюєте зі списками елементів? 👇