Frontend'da qanday testlash darajalari bor va ularni qaysi vositalar bilan qamrab olinadi?
Savol
Frontend'ga nisbatan testlash piramidasi nima va har bir darajada qanday vositalar ishlatiladi?
Qisqa javob
Testlash piramidasi — bu testlar sonining darajalar bo'yicha nisbati: asosda ko'plab tez va arzon unit-testlar (Jest/Vitest), kamroq xatti-harakatni tekshiradigan komponent testlari (Testing Library), va tepada juda kam sonli sekin, lekin eng realistik E2E-testlar (Playwright/Cypress).
Batafsil javob
- Unit-testlar (Jest / Vitest) — izolyatsiya qilingan funksiyalar va modullarni testlaydi: utilitalar, helperlar, redyuserlar, DOM'siz composable'lar. Xotirada ishga tushadi (DOM zaglushkasi kerak bo'lsa jsdom/happy-dom), millisekundlarda bajariladi, katta miqdorda yozish oson. Izolyatsiya qilingan koddagi mantiqiy xatolarni ushlaydi, lekin modullar bir-biri bilan qanday ishlashi haqida hech narsa bilmaydi.
- Komponent testlari (Testing Library —
@testing-library/vue,@testing-library/react) — komponentni render qiladi va uning foydalanuvchi nuqtai nazaridan xatti-harakatini tekshiradi: ekranda nima ko'rinadi, bosishda nima sodir bo'ladi — amalga oshirishning ichki tafsilotlari emas (komponentning "state.count === 1" emas, balki "bosgandan keyin ekranda '1' yozilgan" degani). Testing Library falsafasi ataylab komponentning ichkarisiga kirishni cheklaydi (instance/state'ga to'g'ridan-to'g'ri kirish yo'q), toki testlar amalga oshirish qayta ishlanganda emas, balki xatti-harakat haqiqatan o'zgarganda buzilsin. Bu unit-testlarga qaraganda sekinroq (DOM kerak), lekin komponentning shablon/stillar/hodisalar bilan integratsiyasini qamrab oladi. - E2E-testlar (Playwright / Cypress) — butun ilovani haqiqiy (yoki haqiqiyga yaqin) brauzerda ishga tushiradi, haqiqiy UI'ga bosadi, haqiqiy tarmoq so'rovlari bo'ylab yuradi (yoki ularni tarmoq darajasida mocklaydi). Login, buyurtma rasmiylashtirish kabi to'liq foydalanuvchi ssenariysini barcha qatlamlar orqali tekshiradi: front, API, ba'zan MB. Eng sekin va qo'llab-quvvatlashda eng qimmat (taymingi/tarmoq tufayli beqarorlik), lekin haqiqatga eng yaqin: unit- va komponent testlar printsipial jihatdan ko'ra olmaydigan integratsiya baglarini ushlaydi.
Piramidaning kelishuvi (trade-off): daraja qanchalik yuqori bo'lsa, test shunchalik qimmat (bajarilish vaqti, yozish vaqti, barqarorlik) va haqiqiy foydalanuvchi tajribasiga shunchalik yaqin bo'ladi. Shu sababli tekshiruvlarning asosiy qismini unit- va komponent testlar bilan qamrab olishga harakat qilinadi, E2E esa har bir mayda narsa uchun emas, balki muhim end-to-end ssenariylar (checkout, avtorizatsiya) uchun qoldiriladi.
Alohida kategoriya — vizual regressiya testlash (screenshot testing): vosita (Playwright, Storybook uchun Chromatic, Percy) komponent/sahifaning skrinshotini oladi va uni piksel-piksel etalon bilan solishtiradi, oddiy assertion-testlar sezmaydigan bila qasddan bo'lmagan vizual o'zgarishlarni (tugma siljidi, chekinishlar buzildi) ushlash uchun.
Misol
// sum.test.js — unit-test (Vitest)
import { describe, it, expect } from 'vitest'
import { sum } from './sum'
describe('sum', () => {
it('ikki sonni qo\'shadi', () => {
expect(sum(2, 3)).toBe(5)
})
})
// Counter.test.js — komponent testi (Testing Library)
import { render, screen, fireEvent } from '@testing-library/vue'
import Counter from './Counter.vue'
test('bosilganda hisoblagichni oshiradi', async () => {
render(Counter)
const button = screen.getByRole('button', { name: /increment/i })
await fireEvent.click(button)
// foydalanuvchi ko'radigan narsani tekshiramiz, ichki state emas
expect(screen.getByText('Count: 1')).toBeInTheDocument()
})
// checkout.spec.ts — E2E-test (Playwright)
import { test, expect } from '@playwright/test'
test('foydalanuvchi buyurtma rasmiylashtira oladi', async ({ page }) => {
await page.goto('/cart')
await page.getByRole('button', { name: 'Buyurtma berish' }).click()
await page.getByLabel('Email').fill('user@example.com')
await page.getByRole('button', { name: "To'lash" }).click()
await expect(page.getByText('Buyurtma rasmiylashtirildi')).toBeVisible()
})
Qo'shimcha savollar
- Nega Testing Library ataylab komponentning ichki state'iga oson kirishni bermaydi?
- "Flaking" (beqaror) E2E-testlar bilan qanday kurashish mumkin?
- Qaysi hollarda komponent testini E2E'ga almashtirish kerak, va aksincha?