Testing

01Թեստերի բուրգը

Մտածեք մեքենայի ստուգման մասին։ Յուրաքանչյուր դետալ ստուգում եք ստենդի վրա (unit թեստեր)՝ շատ, արագ, էժան։ Համակարգերը ստուգում եք միասին՝ շարժիչը փոխանցման տուփի հետ (integration և feature թեստեր)՝ ավելի քիչ, ավելի դանդաղ։ Հետո ամբողջ մեքենան տանում եք փորձնական երթի (end-to-end թեստեր)՝ քիչ, ամենադանդաղ, բայց իրականությանն ամենամոտ։ Բուրգն ասում է՝ ներքևում շատ unit թեստեր, integration թեստերի ամուր շերտ, վերևում E2E-ի բարակ շերտ։ Backend API-ների համար շատ թիմեր նախընտրում են «գավաթի» ձևը, որտեղ ամենամեծ շերտը feature թեստերն են, որոնք կանչում են իրական endpoint-ներ իրական թեստային բազայով, որովհետև բագերի մեծ մասը հենց այնտեղ է ապրում։ Ամեն դեպքում՝ արագ թեստերն աշխատում են անընդհատ, դանդաղները ծածկում են միայն կրիտիկական սցենարները։

• Unit. մեկ ֆունկցիա կամ class՝ առանց տվյալների բազայի կամ ցանցի։
• Feature / integration. HTTP հարցումը մտնում է, ստուգվում են տվյալների բազան և պատասխանը։
• E2E. իրական բրաուզեր կամ սարք, որն անցնում է իրական UI-ով և API-ով։

02PHPUnit և Pest Laravel-ի համար

Laravel-ը գալիս է PHPUnit-ով և Pest-ով (ավելի հաճելի syntax PHPUnit-ի վրա)։ Feature թեստերը HTTP հարցումներ են ուղարկում ձեր հավելվածին հիշողության մեջ և assert են անում պատասխանի, տվյալների բազայի և side effect-ների վրա։ Օգտագործեք RefreshDatabase trait-ը, որպեսզի յուրաքանչյուր թեստ սկսվի մաքուր վիճակից. թեստերը գործարկեք նույն database engine-ի դեմ, ինչ production-ում (MySQL կամ PostgreSQL), որովհետև SQLite-ը եզրային դեպքերում այլ կերպ է իրեն պահում։ Factory-ները մեկ տողով ստեղծում են իրատեսական մոդելներ՝ state-ներով տարբերակների համար, օրինակ՝ վճարված պատվեր կամ արգելափակված օգտատեր։ Laravel-ի fake-երը փոխարինում են արտաքին ազդեցությունները. Queue::fake, Mail::fake, Notification::fake, Event::fake և Http::fake թույլ են տալիս assert անել, որ ինչ-որ բան ուղարկվել է՝ առանց այն իրականում ուղարկելու։

1it('lets a customer place an order', function () {
2    Queue::fake();
3    $user = User::factory()->create();
4    $product = Product::factory()->create(['price' => 2500]);
5 
6    $this->actingAs($user)
7        ->postJson('/api/v1/orders', ['items' => [['product_id' => $product->id, 'qty' => 2]]])
8        ->assertCreated()
9        ->assertJsonPath('data.total', 5000);
10 
11    $this->assertDatabaseHas('orders', ['user_id' => $user->id, 'total' => 5000]);
12    Queue::assertPushed(SendOrderConfirmation::class);
13});

03Jest, Vitest և node:test TypeScript-ի համար

JavaScript-ի աշխարհում Vitest-ը ժամանակակից default-ն է Vite-ի վրա հիմնված և նոր TypeScript նախագծերի մեծ մասի համար՝ արագ, ESM-native և Jest-համատեղելի։ Jest-ը դեռ տարածված է, հատկապես React Native-ում և ավելի հին codebase-երում։ Node-ն ունի նաև ներկառուցված runner՝ node:test, ընդհանրապես առանց dependency-ների։ NestJS-ի համար օգտագործեք testing module-ը՝ հավելվածի մի հատված կառուցելու և provider-ները fake-երով փոխարինելու համար. API թեստերի համար supertest-ը հարցումներ է ուղարկում հավելվածին։ Մաքուր տրամաբանությունը (գնագոյացում, թույլտվություններ, ամսաթվերի կանոններ) ստուգեք բազմաթիվ փոքր unit թեստերով, իսկ endpoint-ները՝ իրական PostgreSQL-ի դեմ Docker-ում կամ Testcontainers-ով, այլ ոչ թե ORM-ը mock անելով։

1import { describe, it, expect } from 'vitest';
2import { applyPromotion } from './pricing';
3 
4describe('applyPromotion', () => {
5  it('never discounts below zero', () => {
6    expect(applyPromotion({ subtotal: 1000 }, { type: 'fixed', amount: 1500 }).total).toBe(0);
7  });
8 
9  it('applies percentage to subtotal only, not delivery', () => {
10    const r = applyPromotion({ subtotal: 10_000, delivery: 500 }, { type: 'percent', amount: 10 });
11    expect(r.total).toBe(9_500);
12  });
13});

04Playwright end-to-end թեստերի համար

Playwright-ը կառավարում է իրական Chromium, Firefox և WebKit բրաուզերներ։ Այն ավտոմատ սպասում է էլեմենտներին, ուստի թեստերը շատ ավելի քիչ են flaky, քան հին գործիքների դեպքում, և երբ ինչ-որ բան ձախողվում է, գրանցում է trace-եր՝ screenshot-ներով և ցանցային log-երով։ E2E թեստեր գրեք այն մի քանի սցենարների համար, որոնք գումար են բերում կամ կորցնում. մուտք, զամբյուղ ավելացնել և checkout, ադմինի հիմնական գործողություն։ Էլեմենտներն ընտրեք ըստ role-ի և տեսանելի տեքստի, այնպես, ինչպես օգտատերերն են գտնում դրանք, այլ ոչ թե CSS class-ներով։ Յուրաքանչյուր թեստին անհրաժեշտ տվյալները seed արեք API-ի կամ fixture-ի միջոցով, այլ ոչ թե setup էկրաններով սեղմելով, և հավաքածուն գործարկեք staging-ի նման միջավայրում՝ արտաքին ծառայությունները stub արված։

1import { test, expect } from '@playwright/test';
2 
3test('guest can check out', async ({ page }) => {
4  await page.goto('/products/sample-product');
5  await page.getByRole('button', { name: 'Add to cart' }).click();
6  await page.getByRole('link', { name: 'Cart' }).click();
7  await page.getByRole('button', { name: 'Checkout' }).click();
8  await page.getByLabel('Phone').fill('+10000000000');
9  await page.getByRole('button', { name: 'Place order' }).click();
10  await expect(page.getByRole('heading', { name: 'Thank you' })).toBeVisible();
11});

05Արտաքին ծառայությունների mock և fixture-ներ

Ձեր թեստերը երբեք չպետք է կանչեն իրական վճարային gateway, SMS պրովայդեր կամ ERP։ Փոխարինեք դրանք սահմանի վրա. յուրաքանչյուր ինտեգրացիա փաթեթավորեք ձեր սեփական client class-ի մեջ, իսկ թեստերում այն փոխարինեք fake-ով կամ stub արեք դրա HTTP կանչերը (Laravel-ում՝ Http::fake, Node-ում՝ MSW կամ nock)։ Իրատեսական պատասխանները, ներառյալ սխալներն ու timeout-ները, գրանցեք որպես fixture-ներ, որպեսզի ստուգեք նաև ձախողման ճանապարհները։ Mock մի արեք այն, ինչ ձերն է, օրինակ՝ ձեր սեփական service-ները կամ տվյալների բազան. չափից շատ mock-ը տալիս է թեստեր, որոնք անցնում են, մինչ production-ը կոտրվում է։ Factory-ները թեստային տվյալներ են կառուցում խելամիտ default-ներով, այնպես որ յուրաքանչյուր թեստ նշում է միայն այն, ինչ իր համար կարևոր է։ Թեստերը պահեք անկախ. ոչ մի ընդհանուր state, ոչ մի պարտադիր հերթականություն։

06Թեստավորում CI-ում և ինչը ստուգել առաջինը

Lint-ը, type check-երը և թեստերը գործարկեք յուրաքանչյուր pull request-ի վրա և արգելափակեք merge-ը, երբ դրանք ձախողվում են։ CI job-ում օգտագործեք իրական database service, թեստերը գործարկեք զուգահեռ և cache արեք dependency-ները, որպեսզի feedback-ը գա րոպեների ընթացքում։ Եթե E2E-ն դանդաղ է, գործարկեք այն main-ի վրա կամ գիշերը։ Իրական պրոդուկտում, որտեղ թեստեր չկան, մի ձգտեք coverage-ի թվերի։ Սկսեք այնտեղից, որտեղ բագն ամենաթանկն է նստում. գումար (checkout-ի ընդհանուր գումարներ, զեղչեր, վերադարձներ, վճարման callback-ներ), թույլտվություններ և tenant-ների մեկուսացում, ինչպես նաև state machine-ներ, օրինակ՝ պատվերի կարգավիճակը։ Այնուհետև յուրաքանչյուր շտկված բագի համար ավելացրեք թեստ, որպեսզի այն երբեք չվերադառնա։ Coverage-ը բնականորեն աճում է այնտեղ, որտեղ դա կարևոր է։

1# .github/workflows/test.yml (excerpt)
2jobs:
3  test:
4    runs-on: ubuntu-latest
5    services:
6      postgres:
7        image: postgres:17
8        env: { POSTGRES_PASSWORD: postgres, POSTGRES_DB: app_test }
9        ports: ["5432:5432"]
10    steps:
11      - uses: actions/checkout@v4
12      - uses: pnpm/action-setup@v4
13      - uses: actions/setup-node@v4
14        with: { node-version: 24, cache: pnpm }
15      - run: pnpm install --frozen-lockfile
16      - run: pnpm typecheck && pnpm lint && pnpm test

07Արագ, մեկուսացված տվյալների բազայի թեստեր

Տվյալների բազայի թեստերը backend-ի ամենաարժեքավոր թեստերն են և ամենահեշտը դանդաղեցնելու համար։ Մեկուսացման ռազմավարությունները՝ ամենաարագից սկսած. յուրաքանչյուր թեստ փաթաթել տրանզակցիայի մեջ և հետ գլորել (Laravel-ի RefreshDatabase-ը դա անում է՝ մեկ գործարկման ընթացքում մեկ անգամ միգրացիա անելուց հետո, իսկ LazilyRefreshDatabase-ը բաց է թողնում միգրացիան, եթե թեստը բազային ընդհանրապես չի դիպչում). թեստերի միջև մաքրել աղյուսակները (truncate), երբ թեստավորվող կոդը բացում է իր սեփական տրանզակցիաները կամ կապերը. կամ ամբողջությամբ վերստեղծել բազան, ինչը ամենադանդաղն է։ Գործարկեք զուգահեռ. php artisan test --parallel-ը յուրաքանչյուր պրոցեսի տալիս է սուֆիքսով սեփական բազա, որպեսզի թեստերը չբախվեն։ Node-ում Testcontainers-ը յուրաքանչյուր գործարկման համար Docker-ում բարձրացնում է իրական PostgreSQL, այնպես որ CI-ն ու նոութբուքերը օգտագործում են նույն շարժիչն ու տարբերակը, ինչ production-ը։ Արագության հնարքներ՝ CI-ում բազան պահեք tmpfs-ի վրա, PostgreSQL-ում մեկ անգամ միգրացիա արեք և կլոնավորեք template բազայից, և երբեք sleep մի օգտագործեք թեստերում։

1import { before, after } from 'node:test';
2import { execSync } from 'node:child_process';
3import { PostgreSqlContainer, type StartedPostgreSqlContainer } from '@testcontainers/postgresql';
4 
5let pg: StartedPostgreSqlContainer;
6 
7before(async () => {
8  pg = await new PostgreSqlContainer('postgres:17').start();
9  process.env.DATABASE_URL = pg.getConnectionUri();
10  execSync('npx prisma migrate deploy', { stdio: 'inherit' });
11});
12 
13after(async () => {
14  await pg.stop();
15});

08Օրինակներից այն կողմ՝ property-based և mutation testing

Օրինակային թեստերը ստուգում են այն դեպքերը, որոնց մասին դուք մտածել եք։ Property-based testing-ը կանոնները ստուգում է հարյուրավոր գեներացված մուտքերի վրա. «1,000-ի վրա 10% զեղչը տալիս է 900»-ի փոխարեն դուք ձևակերպում եք՝ «ցանկացած ենթագումարի և 0-ից 100 ցանկացած տոկոսի դեպքում ընդհանուր գումարը երբեք բացասական չէ և երբեք չի գերազանցում ենթագումարը»։ TypeScript-ի համար fast-check-ի նման գրադարանները գեներացնում են մուտքեր և, երբ դեպքը ձախողվում է, այն փոքրացնում են մինչև ամենափոքր ձախողվող օրինակը։ Այն փայլում է գնագոյացման, կլորացման, parsing-ի և ամսաթվերի տրամաբանության համար։ Mutation testing-ը չափում է, թե որքան լավն են ձեր թեստերը, այլ ոչ թե որքան կոդ են դրանք գործարկում։ PHP-ի համար Infection-ը և JavaScript-ի համար Stryker-ը փոքր փոփոխություններ են անում ձեր կոդում, օրինակ՝ >=-ը դարձնում են >, և նորից գործարկում թեստերը։ Եթե թեստերը դեռ անցնում են, այդ մուտանտը ողջ է մնացել, ինչը ցույց է տալիս, որ assertion է պակասում։ Coverage-ն ասում է, որ տողը գործարկվել է, իսկ mutation score-ը՝ որ թեստը կնկատեր, եթե այն սխալ լիներ։

1import fc from 'fast-check';
2import { test, expect } from 'vitest';
3import { applyPromotion } from './pricing';
4 
5test('percentage promotions stay within 0 and the subtotal', () => {
6  fc.assert(
7    fc.property(
8      fc.integer({ min: 0, max: 10_000_000 }),
9      fc.integer({ min: 0, max: 100 }),
10      (subtotal, percent) => {
11        const { total } = applyPromotion({ subtotal }, { type: 'percent', amount: percent });
12        expect(total).toBeGreaterThanOrEqual(0);
13        expect(total).toBeLessThanOrEqual(subtotal);
14      },
15    ),
16  );
17});

09Ճարտարապետական և պայմանագրային (contract) թեստեր

Որոշ կանոններ վարքագծի մասին չեն, այլ կառուցվածքի, և թեստերը կարող են պաշտպանել նաև դրանք։ Pest-ի architecture testing-ը թույլ է տալիս պնդել, որ controller-ները երբեք չեն օգտագործում DB facade-ը, որ domain շերտը երբեք չի ներմուծում HTTP դասեր, կամ որ debug ֆունկցիաները, օրինակ՝ dd()-ն, չեն հասնում production։ Այն նաև ունի պատրաստի preset-ներ տարածված կանոնների համար։ Հավելվածների և ծառայությունների միջև contract թեստերը բռնում են սխալների ամենաթանկ դասը. մի կողմը փոխում է դաշտ, որից կախված է մյուսը։ Consumer-driven contract-ների դեպքում (ամենահայտնի գործիքը Pact-ն է) սպառողը գրանցում է, թե ինչ է սպասում մատակարարից, իսկ մատակարարի CI-ն ստուգում է, որ այն դեռ բավարարում է բոլոր սպառողներին։ Ավելի թեթև տարբերակ է feature թեստերում իրական API պատասխանները ձեր OpenAPI սխեմայով վավերացնելը։ Երկուսն էլ շատ ավելի արագ և ճշգրիտ են, քան լիարժեք end-to-end թեստերը՝ ապացուցելու համար, որ երկու համակարգերը դեռ համաձայն են միմյանց հետ։

1// tests/ArchTest.php (Pest)
2arch()->preset()->php();       // e.g. no dd(), dump() or var_dump()
3arch()->preset()->security();  // flags eval(), md5(), sha1() and similar
4 
5arch('controllers do not query the database directly')
6    ->expect('App\Http\Controllers')
7    ->not->toUse('Illuminate\Support\Facades\DB');
8 
9arch('domain does not depend on HTTP')
10    ->expect('App\Domain')
11    ->not->toUse('Illuminate\Http');

10Ժամանակի, կրկնությունների և զուգահեռության թեստավորում

Production հասնող սխալները հաճախ ժամանակի և կրկնության մասին են. բաժանորդագրություն, որը մեկ վայրկյան շուտ է ավարտվում, job, որը retry-ի ժամանակ կրկնակի է ուղարկում, երկու հարցում, որոնք պահեստից ավելին են վաճառում։ Թեստավորեք դրանք դիտավորյալ։ Սառեցրեք կամ տեղափոխեք ժամանակը՝ սպասելու փոխարեն. Laravel-ի travelTo() և travel(), Carbon::setTestNow(), կամ Vitest-ում vi.useFakeTimers() և vi.setSystemTime()։ Թեստավորեք սահմանները՝ վերջնաժամկետից մեկ վայրկյան առաջ և հետո, ինչպես նաև ժամային գոտիները կեսգիշերին և ամառային ժամանակի անցումների շուրջ։ Idempotency-ի համար նույն job-ը կամ webhook-ը գործարկեք երկու անգամ և պնդեք, որ էֆեկտը մեկն է։ Race condition-ների դեպքում mock-երով unit թեստը ոչինչ չի ապացուցում. իրական զուգահեռ հարցումներ ուղարկեք իրական բազայի դեմ, օրինակ՝ Promise.all-ով integration թեստում կամ կարճ k6 սկրիպտով, և պնդեք, որ ինվարիանտը, օրինակ՝ պահեստի մնացորդը երբեք զրոյից ցածր չէ, դեռ պահպանվում է։

1it('expires a subscription exactly at its end time', function () {
2    $sub = Subscription::factory()->create(['ends_at' => '2026-03-01 00:00:00']);
3 
4    $this->travelTo('2026-02-28 23:59:59');
5    $this->artisan('subscriptions:expire')->assertSuccessful();
6    expect($sub->fresh()->status)->toBe(SubscriptionStatus::Active);
7 
8    $this->travelTo('2026-03-01 00:00:01');
9    $this->artisan('subscriptions:expire')->assertSuccessful();
10    expect($sub->fresh()->status)->toBe(SubscriptionStatus::Expired);
11});
12 
13it('creates one invoice even if the job runs twice', function () {
14    $order = Order::factory()->paid()->create();
15    GenerateInvoice::dispatchSync($order->id);
16    GenerateInvoice::dispatchSync($order->id);
17    expect(Invoice::where('order_id', $order->id)->count())->toBe(1);
18});