Mundarija (33)
- Bu darsda
- 1. Nega bu kerak?
- 2. node --test: fayllarni topish va ishga tushirish
- 2.1 Qaysi fayllar?
- 2.2 Har fayl — alohida jarayon
- 3. describe, it va hook'lar
- 3.1 To'liq misol
- 3.2 Hook'lar
- 3.3 Tanlab ishga tushirish
- 4. node:assert/strict
- 4.1 Nega strict
- 4.2 Kerakli tekshiruvlar
- 4.3 Yiqilgan test qanday ko'rinadi
- 5. t.mock va snapshot
- 5.1 t.mock — qisqacha
- 5.2 Snapshot test
- 6. --watch va boshqa bayroqlar
- 7. node:test yoki Vitest — o'lchov
- 8. API qadami: kod o'zgarmaydi (holat 51, 2-qism)
- 9. Ko'p uchraydigan xatolar
- 9.1 Legacy assert
- 9.2 Obyektni equal bilan solishtirish
- 9.3 Argumentlar tartibi
- 9.4 Glob qo'shtirnoqsiz
- 9.5 await siz async tekshiruv
- 10. Mashqlar
- 1-mashq (oson): qaysi tekshiruv?
- 2-mashq (o'rta): hook'lar tartibi
- 3-mashq (qiyin): o'z mini-runner'ingiz
- 4-mashq: API qadami — runner'ni sinash
- 11. Real ishda
- Xulosa
- Manbalar
node:test va node:assert: Node'ning o'rnatilgan test runner'i chuqur
Qisqacha: Node 24 da test yozish uchun kutubxona shart emas:
node:test(runner —describe,it, hook'lar,t.mock, snapshot) vanode:assert/strict(tekshiruvlar) o'rnatilgan.node --test "test/**/*.test.ts"har faylni alohida jarayonda ishga tushiradi, TypeScript'ni ham type stripping bilan to'g'ridan bajaradi. Kanon o'lchovidavazifalar-apining 62 testinode --testbilan 2.5 s, Vitest bilan 3.0–3.3 s ketdi, bitta trivial test — 212 ms va 758 ms. Shuning uchun backend'danode:testqoldi: tezroq va 0 bog'liqlik.
Bu darsda
node --testfayllarni qanday topishini va ishga tushirishini tushuntirasiz.describe/it, hook'lar,skip,todo,--test-name-patternbilan ishlaysiz.assertning strict rejimini va eng kerakli tekshiruvlarini to'g'ri tanlaysiz.- Snapshot testni yozib, uni yangilashni bilasiz.
node:testva Vitest'ni o'lchov bilan solishtira olasiz.
Oldin bilishingiz kerak: Birinchi avtomatik test: node:test va assert, Vitest I, TypeScript'ni Node'da to'g'ridan ishga tushirish, Backend test strategiyasi.
1. Nega bu kerak?
12-qismda birinchi testni node:test bilan yozgansiz: test(), assert.equal, node --test. 22-qismda frontend uchun Vitest'ni o'rgandingiz — jsdom, brauzer rejimi, React. Endi backend. Qaysi birini olamiz?
vazifalar-api boshidan node:test bilan keldi. Holat 51 da kanon savol berdi: "Vitest'ga o'tsak yaxshiroq bo'ladimi?" — va o'lchadi. Bu darsda runner'ni chuqur o'rganamiz va o'sha o'lchovni ko'ramiz.
Hayotiy o'xshatish: uyda asboblar qutisi. Usta har ish uchun do'kondan yangi asbob olib kelmaydi — avval qutida borini ishlatadi. node:test — Node'ning qutisida bor asbob. Maxsus asbob (Vitest) faqat haqiqatan kerak bo'lganda olinadi: frontend'da jsdom va brauzer rejimi kerak edi, backend'da — yo'q.
2. node --test: fayllarni topish va ishga tushirish
2.1 Qaysi fayllar?
Argumentsiz node --test joriy papkadan sukut naqshlarga mos fayllarni qidiradi: *.test.{js,mjs,cjs}, *-test.*, *_test.*, test-*.*, test.* va test/ papkasidagilar. Node 24 da type stripping sukut bo'yicha yoqilgan, shuning uchun xuddi shu naqshlar .ts, .mts, .cts uchun ham ishlaydi (Node 24 hujjati). Kanon esa naqshni aniq beradi:
{
"scripts": {
"test": "node --test \"test/**/*.test.ts\""
}
}Naqsh qo'shtirnoq ichida — buni Node o'zi kengaytiradi. Qo'shtirnoqsiz bo'lsa, Linux'da shell kengaytiradi (** ni ba'zi shell'lar tushunmaydi), Windows cmd esa umuman kengaytirmaydi. Qo'shtirnoq — hamma joyda bir xil natija.
ombor-shartnoma.ts va yordamchi.ts naqshga tushmaydi (.test.ts emas) — ular test emas, testlar import qiladigan modul.
2.2 Har fayl — alohida jarayon
node --test har test faylini alohida bola jarayonda ishga tushiradi va natijalarni yig'adi. Bu ikki narsa beradi:
- Izolyatsiya: bir fayldagi global o'zgarish (
process.env, modul holati) boshqasiga o'tmaydi. - Parallellik: fayllar bir vaqtda yuradi (
--test-concurrencybilan cheklash mumkin; sukut —os.availableParallelism() - 1, ya'ni yadrolar sonidan bitta kam).
Shuning uchun kanon serverlarni port 0 da ochadi: parallel fayllar bir portda to'qnashmaydi.
3. describe, it va hook'lar
3.1 To'liq misol
Teglar funksiyasini tekshiramiz (regex kanondagidan soddalashtirilgan — apostrofli teglarsiz):
import { describe, it, before, beforeEach, after } from "node:test";
import assert from "node:assert/strict";
const TEG = /(?<![\p{L}\p{N}_#])#([\p{L}\p{N}_]+)/gu;
const teglariniOl = (matn) => [
...new Set([...matn.matchAll(TEG)].map((m) => m[1].toLowerCase())),
];
describe("teglariniOl", () => {
let chaqiruv = 0;
before(() => console.log("before: bir marta"));
beforeEach(() => chaqiruv++);
after(() => console.log(`after: ${chaqiruv} ta test`));
it("bitta teg", () => {
assert.deepEqual(teglariniOl("Non olish #uy"), ["uy"]);
});
it("katta harf va takror", () => {
assert.deepEqual(teglariniOl("#Uy #uy #ish"), ["uy", "ish"]);
});
it("so'z ichidagi # — teg emas", () => {
assert.deepEqual(teglariniOl("Non#uy"), []);
});
it.skip("emoji teglar", () => {});
it.todo("teglar soni chegarasi");
});Biz ishga tushirdik (node --test, Node 24.21.0; vaqtlar har safar boshqacha). Chiqishda ikki narsaga qarang: console.log qatorlari qayerda chiqdi va oxiridagi hisobda nechta test bor:
before: bir marta
after: 4 ta test
▶ teglariniOl
✔ bitta teg (2.8986ms)
✔ katta harf va takror (0.2632ms)
✔ so'z ichidagi # — teg emas (0.1894ms)
﹣ emoji teglar (0.0982ms) # SKIP
✔ teglar soni chegarasi (0.2182ms) # TODO
✔ teglariniOl (5.8653ms)
ℹ tests 5
ℹ suites 1
ℹ pass 3
ℹ fail 0
ℹ cancelled 0
ℹ skipped 1
ℹ todo 1
ℹ duration_ms 107.2241Uchta kuzatuv:
console.loglar natijalardan oldin chiqdi — reporter natijalarni oxirida tartib bilan chop etadi.beforeEach4 marta ishladi: 3 ta test +todo.skipuchun hook ishlamaydi,todouchun ishlaydi. Hujjatga ko'ratodotest bajariladi, lekin yiqilsa ham xato hisoblanmaydi; funksiyasiztodoesa bilan "o'tgan" bo'lib chiqdi.pass 3,skipped 1,todo 1— jami 5.todovaskipCI'ni yiqitmaydi.
describe — suite ning boshqa nomi, it — test ning. Kanon asosan ichma-ich bo'lmagan test() ishlatadi; describe — shartnoma testlarida (VazifaOmbori shartnomasi: xotira).
3.2 Hook'lar
| Hook | Qachon | Kanonda |
|---|---|---|
before |
describe (yoki fayl) boshida bir marta |
server ochish (ishgaTushir()) |
after |
oxirida bir marta | serverni yopish |
beforeEach / afterEach |
har testdan oldin / keyin | ishlatilmagan |
t.after(fn) |
shu test tugagach | vaqtinchalik papkalarni o'chirish |
Kanon ombor.test.ts dagi test.after(...) — yuqori darajadagi after: fayldagi hamma testlardan keyin vaqtinchalik papkalarni o'chiradi.
3.3 Tanlab ishga tushirish
--test-name-pattern="katta"— nomida "katta" bor testlar. Yuqoridagi faylda faqat bittasi yurdi (ℹ tests 1) — biz sinadik;before/afterbaribir ishladi.it.only(...)+node --test --test-only— faqat belgilanganlar. Bayroqsizonlyta'sir qilmaydi — commit'da unutib qoldirsangiz CI barcha testlarni yuritadi, bu yaxshi.--test-skip-pattern— teskarisi.
Tekshirib ko'ring: Nega kanon har test faylida
beforeda yangi server ochadi, umumiy bitta server emas?
Javob
Har fayl alohida jarayonda ishlaydi — umumiy server bo'lishi ham mumkin emas (jarayonlar xotirani bo'lishmaydi). Bundan tashqari, alohida server — alohida ombor: bir fayldagi vazifalar boshqa faylning "ro'yxat bo'sh" kutishini buzmaydi. Port 0 tufayli fayllar parallel yurganda ham to'qnashmaydi.
4. node:assert/strict
4.1 Nega strict
node:assert ning ikki rejimi bor. Eski (legacy) rejimda assert.equal == bilan solishtiradi — 1 va "1" teng. Strict rejimda equal = strictEqual, deepEqual = deepStrictEqual. Kanon har doim import assert from "node:assert/strict".
import assert from "node:assert/strict";
import * as eski from "node:assert";
function sina(nom, fn) {
try {
fn();
console.log(`✔ ${nom}`);
} catch (x) {
const birinchi = x.message.split("\n")[0];
console.log(`✘ ${nom}: ${x.code} — ${birinchi}`);
}
}
sina("eski equal", () => eski.equal(1, "1"));
sina("strict equal", () => assert.equal(1, "1"));
sina("obyekt equal", () => assert.equal({ id: 1 }, { id: 1 }));
sina("deepEqual", () => assert.deepEqual({ id: 1 }, { id: 1 }));
sina("massiv tartibi", () => assert.deepEqual([1, 2], [2, 1]));Konsolda:
✔ eski equal
✘ strict equal: ERR_ASSERTION — Expected values to be strictly equal:
✘ obyekt equal: ERR_ASSERTION — Values have same structure but are not reference-equal:
✔ deepEqual
✘ massiv tartibi: ERR_ASSERTION — Expected values to be strictly deep-equal:Har qatorni o'qiymiz:
- eski equal —
1 == "1"rost, test o'tdi. Xato yashirinib qoldi: API son o'rniga satr qaytarsa, sezmaysiz. - strict equal — "Expected values to be strictly equal" — "qiymatlar qat'iy teng bo'lishi kutilgan edi".
- obyekt equal — "Values have same structure but are not reference-equal" — "tuzilma bir xil, lekin bu boshqa-boshqa obyektlar".
equalhavolani solishtiradi; obyekt uchundeepEqualkerak. Xabar o'zi maslahat beryapti. - massiv tartibi —
deepEqualtartibga sezgir. Kanonda teglar tartibi ataylab tekshiriladi (["uy", "ish"]).
4.2 Kerakli tekshiruvlar
| Metod | Nima uchun | Kanon misoli |
|---|---|---|
equal |
primitiv | assert.equal(r.status, 201) |
deepEqual |
obyekt, massiv | assert.deepEqual(v.teglar, ["uy"]) |
match / doesNotMatch |
satr regex'ga mosmi | ISO vaqt; SOXTA-TOKEN logda yo'q |
ok |
rostmi (va TypeScript'ga "bor" deydi) | assert.ok(xizmat) |
throws / rejects |
xato kutiladi | ConfigXatosi |
partialDeepStrictEqual |
faqat ko'rsatilgan maydonlar | — |
Yana uchtasini sinaymiz:
import assert from "node:assert/strict";
assert.match("2026-10-24T06:04:48.964Z", /^\d{4}-\d{2}-\d{2}T.*Z$/);
assert.throws(() => JSON.parse("{"), { name: "SyntaxError" });
assert.partialDeepStrictEqual(
{ id: 1, matn: "Non", teglar: [] },
{ matn: "Non" },
);
await assert.rejects(Promise.reject(new TypeError("x")), TypeError);
console.log("to'rttasi ham o'tdi");Konsolda:
to'rttasi ham o'tdithrows ga obyekt bersangiz — xatoning faqat shu maydonlari solishtiriladi (name, message, kod). partialDeepStrictEqual — Node 24.0 dan barqaror (oldin eksperimental edi): kutilgan obyektdagi maydonlar haqiqiyda bo'lsa yetarli, qolganlari (id, teglar) e'tiborsiz. Javobda yaratildi kabi o'zgaruvchan maydon bo'lsa qulay.
assert.ok(x) ning TypeScript'dagi qo'shimcha foydasi: undan keyin kompilyator x ni undefined emas deb biladi. Kanonda const q = qatorlar.find(…); assert.ok(q); assert.equal(q.daraja, "warn") — shu naqsh.
4.3 Yiqilgan test qanday ko'rinadi
Teglarni noto'g'ri kutgan test:
test("xato", () => {
assert.deepEqual(
{ matn: "Non", teglar: ["uy"] },
{ matn: "Non", teglar: ["Uy"] },
);
});Biz ishga tushirdik (izning at … qatorlari olib tashlandi):
✖ xato (2.5977ms)
AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
+ actual - expected
{
matn: 'Non',
teglar: [
+ 'uy'
- 'Uy'
]
}+ actual — haqiqatda kelgani, - expected — kutilgani. Farq aniq qatorda ko'rsatiladi. Birinchi argument doim haqiqiy qiymat, ikkinchisi kutilgan — tartibni almashtirsangiz, + va - teskari bo'lib, chalkashtiradi.
5. t.mock va snapshot
5.1 t.mock — qisqacha
Har test kontekstida (t) mock bor: t.mock.fn(), t.mock.method(), t.mock.timers. Test tugaganda ular avtomatik tiklanadi. Ular — keyingi uch darsning mavzusi: mock, stub, spy, fake, vaqt va tasodif. Bu yerda faqat shakli:
test("stub: ombor.yarat bir marta chaqirildi", async (t) => {
const ombor = new XotiraOmbori();
const yarat = t.mock.method(ombor, "yarat");
// … 3 ta POST bir xil Idempotency-Key bilan
assert.equal(yarat.mock.callCount(), 1);
});5.2 Snapshot test
Snapshot test (snapshot test) — natijani birinchi marta faylga yozib qo'yadi, keyingi yurishlarda shu fayl bilan solishtiradi. node:test da u Node 23.4 dan beri eksperimental emas (hujjat tarixi). Javob shakli katta va o'zgarmasligi kerak bo'lganda qulay — masalan Problem Details:
import { test } from "node:test";
const problem = (status, detail) => ({
type: "about:blank",
title: status === 404 ? "Not Found" : "Error",
status,
detail,
});
test("404 javobi shakli", (t) => {
t.assert.snapshot(problem(404, "Vazifa 9 topilmadi"));
});Biz to'rt bosqichda sinadik (Node 24.21.0):
- Birinchi yurish — yiqildi:
Cannot read snapshot file '…snap.test.mjs.snapshot.' Missing snapshots can be generated by rerunning the command with the --test-update-snapshots flag.— "snapshot fayli yo'q; uni--test-update-snapshotsbilan yarating". node --test --test-update-snapshots— o'tdi va yonidasnap.test.mjs.snapshotfayli paydo bo'ldi:
exports[`404 javobi shakli 1`] = `
{
"type": "about:blank",
"title": "Not Found",
"status": 404,
"detail": "Vazifa 9 topilmadi"
}
`;- Oddiy yurish — o'tdi.
- Kodda
9ni10ga o'zgartirdik — yiqildi, farq bilan:+ "detail": "Vazifa 10 topilmadi",- "detail": "Vazifa 9 topilmadi".
Snapshot faylini git'ga commit qilasiz — u testning bir qismi. Ehtiyot bo'ling: "yiqildi — --test-update-snapshots qildim" odati xatoni ham "to'g'ri" deb yozib qo'yadi. Har yangilashda farqni o'qing. Kanonda snapshot ishlatilmagan: Problem Details maydonlari deepEqual bilan aniq tekshiriladi — o'qish osonroq.
6. --watch va boshqa bayroqlar
| Bayroq | Nima qiladi |
|---|---|
--watch |
fayl saqlanganda tegishli testlarni qayta yuritadi (--watch darsidagi mexanizm) |
--test-concurrency=1 |
fayllarni ketma-ket — tartibga bog'liq xatoni qidirishda |
--test-timeout=5000 |
har test uchun vaqt chegarasi (ms) |
--experimental-test-coverage |
qamrov hisoboti (Coverage) |
--test-reporter=tap |
boshqa format (CI vositalari uchun); sukut — spec |
Diqqat: --test-timeout testning o'zini to'xtatadi, lekin yopilmagan server kabi ochiq resursni emas. Bunday holatni Supertest darsida haqiqiy chiqish bilan ko'ramiz.
7. node:test yoki Vitest — o'lchov
Kanon bir xil test to'plamini (holat 51 nusxasi: 15 fayl, 62 test) ikkala runner'da 3 marta, sovuq ishga tushirdi (t46-runner.txt). Vitest uchun importlar almashtirildi (before → beforeAll, after → afterAll); node:assert Vitest ichida ham o'zgarishsiz ishladi. t.mock li fayl ko'chirilmadi.
- node --test2 542 ms
- Vitest, threads3 044 ms
- Vitest, forks3 265 ms
- 1 test: node212 ms
- 1 test: Vitest758 ms
Manba: IlmHamroh kanon o'lchovi, 2026-10-24: Node 24.21.0, Vitest 5.0.5, Windows 11, i5-12500H (t46-runner.txt), 3 yurish medianasi
| Mezon | node:test |
Vitest 5.0.5 |
|---|---|---|
| 62 test | 2 542 ms | 3 044–3 265 ms |
| 1 trivial test | 212 ms | 758 ms |
| Qo'shimcha paketlar | 0 | +30 (node_modules 227 → 257) |
| TypeScript | type stripping | o'z transformatori |
jsdom, brauzer rejimi, vi.mock hoisting |
yo'q | bor |
Kanon qarori: node:test qoldi. Backend'ga jsdom ham, brauzer ham kerak emas; modul almashtirish (vi.mock) o'rniga bog'liqliklar parametr bilan beriladi (Mock, stub, spy va fake). Qolgani — tezlik va nol bog'liqlik.
Vitest qachon backend'da ham mantiqli? Monorepo'da frontend ham Vitest'da bo'lsa — bitta vosita, bitta sozlama, bitta hisobot. Yoki vi.mock bilan modulni almashtirish shart bo'lgan eski kod. Bu yondashuv ham to'g'ri — o'lchab tanlang.
8. API qadami: kod o'zgarmaydi (holat 51, 2-qism)
vazifalar-api boshidan node:test da. Bugun kodga tegilmaydi — commit qilmang (holat 51 commit'i Coverage darsida). O'rniga runner'ni loyihada sinab ko'rasiz (4-mashq).
Bitta odat: yangi test yozganda avval faqat uni yuriting — node --test --test-name-pattern="supertest" "test/**/*.test.ts" — keyin to'liq npm test. Bu tezroq.
9. Ko'p uchraydigan xatolar
9.1 Legacy assert
import assert from "node:assert" va assert.equal(1, "1") — o'tadi. node:assert/strict.
9.2 Obyektni equal bilan solishtirish
Values have same structure but are not reference-equal. deepEqual.
9.3 Argumentlar tartibi
assert.equal(201, r.status) — farq chiqishida + va - teskari. (haqiqiy, kutilgan).
9.4 Glob qo'shtirnoqsiz
node --test test/**/*.test.ts — Windows'da fayl topilmaydi yoki shell faqat bir darajani kengaytiradi. "test/**/*.test.ts".
9.5 await siz async tekshiruv
assert.rejects(promise) ni await qilmasangiz — test tekshiruv tugashini kutmasdan "o'tadi". await assert.rejects(...).
10. Mashqlar
1-mashq (oson): qaysi tekshiruv?
Har holat uchun assert metodini tanlang: (a) status 204; (b) javob tanasi { id: 1, matn: "Non" }; (c) ETag sarlavhasi " bilan boshlanadi; (d) configYukla({ PORT: "yuz" }) xato tashlaydi; (e) javobda boshqa maydonlar bo'lishi mumkin, lekin kod: "validatsiya" bo'lishi shart.
Yechim
(a) equal(r.status, 204). (b) deepEqual(tana, { id: 1, matn: "Non" }). (c) match(etag, /^"/). (d) throws(() => configYukla({ PORT: "yuz" }), ConfigXatosi) — klass yoki { name: "ConfigXatosi" }. (e) partialDeepStrictEqual(tana, { kod: "validatsiya" }) yoki oddiyroq equal(tana.kod, "validatsiya").
2-mashq (o'rta): hook'lar tartibi
Quyidagi fayl node --test bilan nima chiqaradi (konsol qatorlari tartibi)? Avval o'ylang, keyin ishga tushiring.
import { describe, it, before, beforeEach, after } from "node:test";
describe("tartib", () => {
before(() => console.log("1 before"));
beforeEach(() => console.log("2 beforeEach"));
after(() => console.log("4 after"));
it("a", () => console.log("3 a"));
it("b", () => console.log("3 b"));
});Yechim
Biz ishga tushirdik — konsol qatorlari (reporter natijalaridan oldin):
1 before
2 beforeEach
3 a
2 beforeEach
3 b
4 afterbefore — bir marta, beforeEach — har testdan oldin, after — oxirida. Reporter (▶ tartib, ✔ a …) bu qatorlardan keyin chiqadi — «To'liq misol» bo'limidagi birinchi kuzatuv.
3-mashq (qiyin): o'z mini-runner'ingiz
node:test siz, 30 qatorga yaqin kichik runner yozing: test(nom, fn) testlarni ro'yxatga yig'adi, yurit() ularni ketma-ket bajaradi (async ham), har biri uchun ✔ nom yoki ✘ nom: <xabarning birinchi qatori> chiqaradi, oxirida o'tdi N, yiqildi M. Uchta test bilan sinang: biri o'tadi, biri assert bilan yiqiladi, biri async rejects bilan o'tadi.
Yechim
import assert from "node:assert/strict";
const testlar = [];
const test = (nom, fn) => testlar.push({ nom, fn });
async function yurit() {
let otdi = 0;
let yiqildi = 0;
for (const { nom, fn } of testlar) {
try {
await fn();
otdi++;
console.log(`✔ ${nom}`);
} catch (x) {
yiqildi++;
console.log(`✘ ${nom}: ${x.message.split("\n")[0]}`);
}
}
console.log(`o'tdi ${otdi}, yiqildi ${yiqildi}`);
}
test("qo'shish", () => assert.equal(2 + 2, 4));
test("satr", () => assert.equal("35000", 35000));
test("async xato", () =>
assert.rejects(Promise.reject(new Error("x")), Error));
await yurit();Konsolda:
✔ qo'shish
✘ satr: Expected values to be strictly equal:
✔ async xato
o'tdi 2, yiqildi 1Runner'ning yadrosi shu: ro'yxat, try/await/catch, hisob. node:test bunga izolyatsiya (alohida jarayon), parallellik, hook'lar, vaqt chegarasi, reporter'lar va mock'larni qo'shadi. Uchinchi testda rejects promise qaytaradi — await fn() uni kutadi. fn() ni await siz chaqirsangiz, yiqilgan async test ham "o'tardi" — «await siz async tekshiruv» xatosi.
4-mashq: API qadami — runner'ni sinash
vazifalar-api da: (1) npm test — tests soni nechta? (2) Faqat log testlarini yuriting: node --test --test-name-pattern="sorovId" "test/**/*.test.ts". (3) --test-concurrency=1 bilan to'liq to'plam qancha vaqt oladi, sukut bilan-chi? Kod o'zgarmaydi, commit yo'q.
Yechim
(1) 58 — holat 44 dagidek: bu darsga kelib yangi test qo'shilmagan. Supertest va mock testlari keyingi darslarda qo'shiladi va holat 51 oxirida jami 67 bo'ladi. (2) Nomida sorovId bor testlar yuradi; before hook'lari baribir har faylda ishlaydi. (3) Ketma-ket rejim sekinroq bo'lishi kutiladi — fayllar parallel yurmaydi. Raqamlaringiz mashinaga bog'liq; kanon to'liq to'plam uchun ~2.5–3.4 s o'lchagan (t46-runner.txt, tekshiruv-51.txt).
11. Real ishda
- Node'ning o'zi va ko'plab yangi kutubxonalar
node:testga o'tmoqda — bog'liqliksiz CI tezroq va xavfsizroq. - Eski loyihalarda Jest va Mocha + Chai ko'p uchraydi.
describe/it/beforeg'oyasi hamma joyda bir xil — o'tish asosan importlar (Jest). - CI:
--test-reporter=junityokitap— GitHub Actions va boshqa tizimlar natijani jadval qilib ko'rsatadi (34-qism). - Intervyu savollari: "
assert.equalvadeepEqualfarqi?", "Hook'lar tartibi?", "Snapshot test qachon foydali, qachon zararli?", "Backend uchun qaysi test runner va nega?".
Xulosa
node --test "test/**/*.test.ts"— glob qo'shtirnoqda; har fayl alohida jarayonda, parallel;.tstype stripping bilan.describe/it=suite/test; hook'lar:before,after,beforeEach,afterEach,t.after;skip,todo,--test-name-pattern,--test-only.- Faqat
node:assert/strict:equal,deepEqual,match,throws/rejects(awaitbilan),partialDeepStrictEqual;(haqiqiy, kutilgan)tartibi. - Snapshot: birinchi yurish yiqiladi,
--test-update-snapshotsfaylni yozadi; fayl commit qilinadi, har yangilashda farq o'qiladi. - Kanon o'lchovi: 62 test — 2.5 s (
node:test) va 3.0–3.3 s (Vitest); trivial test 212 va 758 ms;node:testqoldi.
Keyingi dars: Mock, stub, spy va fake — test dublyorlarining turlari, t.mock.fn va t.mock.method, soxta ombor va qachon mock testni yolg'onchi qiladi.
Manbalar
- Node.js hujjati: Test runner (v24) —
describe, hook'lar, snapshot, bayroqlar. - Node.js hujjati: Assert (v24) — strict rejim,
partialDeepStrictEqual. - Kanon:
natijalar/tajriba/t46-runner.txt,vazifalar-apiholat 51 (package.json,test/).
Izohlar (0)
Izoh yozish uchun kiring.
- Hozircha izoh yo'q. Birinchi bo'ling!