💩 Код з душком: Тести-Доміно (або Гріх спільного стану)Привіт, екіпаж! П'ятниця — час вивітрювати "смердючий" код. Сьогодні препаруємо архітектурний антипатерн, який на початку здається геніальною оптимізацією, а через півроку перетворює ваш CI/CD на повільне пекло. Говоримо про залежність тестів (Test Interdependence). ☕️Знайдіть проблему в цьому коді:// ❌ Як пишуть "оптимізатори" (Антипатерн "Доміно")let orderId: string;test.describe('Флоу замовлення', () => { test('Крок 1: Створити замовлення', async ({ page }) => { orderId = await createOrderThroughUI(page); expect(orderId).toBeDefined(); }); test('Крок 2: Оплатити замовлення', async ({ page }) => { // Використовує ID з попереднього тесту! await payForOrder(page, orderId); expect(await getOrderStatus()).toBe('Paid'); }); test('Крок 3: Видалити замовлення', async ({ page }) => { await deleteOrderThroughUI(page, orderId); });}); Чому цей код тхне:Ви порушили головне правило автоматизації — F.I.R.S.T. (Isolated). Ваші тести тепер склеєні суперклеєм. 1️⃣ Крихкість ланцюга: Якщо "Крок 1" падає через випадковий мікро-лаг мережі або рендеру, "Крок 2" і "Крок 3" автоматично стають червоними, бо змінна orderId порожня. У звіті у вас три зламаних тести, хоча реальна проблема лише в одному місці.2️⃣ Паралельність мертва: Ви не зможете запустити ці тести паралельно на кількох воркерах у Playwright (fullyParallel: true), бо вони вимагають суворої послідовності. Ваш пайплайн ніколи не буде швидким.3️⃣ Неможливість локального дебагу: Ви не можете просто взяти і запустити "Крок 3" ізольовано, щоб перевірити логіку видалення. Вам доведеться щоразу чекати, поки проклікаються попередні кроки. ✅ Як це виглядає після код-рев'ю Senior-інженера:Кожен тест має бути повністю незалежним. Він сам готує для себе ідеальні умови (бажано за мілісекунди через API) і сам за собою прибирає.// 🚀 Ідеально чистий код (Повна ізоляція)test('Повинен успішно оплатити замовлення', async ({ request, page }) => { // 1. Arrange: Блискавично створюємо замовлення "під капотом" (через бекенд) const order = await request.post('/api/orders').then(r => r.json()); // 2. Act: Тестуємо саме UI оплати await page.goto(`/orders/${order.id}/pay`); await page.getByRole('button', { name: 'Оплатити' }).click(); // 3. Assert: Перевіряємо результат await expect(page.locator('.status')).toHaveText('Paid');}); Золоте правило: Тест не повинен знати про існування інших тестів. Використовуйте API-виклики (request) або Fixtures для підготовки даних перед дією page.goto(). Кожен запуск — це чиста сторінка.А як у вас справи із залежністю тестів? 👇🔥 — Повна ізоляція, кожен тест готує дані через API за мілісекунди!👀 — У мене величезний test.describe.serial, інакше все ламається...🤯 — А що, тести можна запускати в довільному порядку?!