IlmHamroh
JavaScript Full-stack/25-qism. HTTP, Express va REST API46/51-dars15 daqiqa
Mundarija (33)

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) va node: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'lchovida vazifalar-api ning 62 testi node --test bilan 2.5 s, Vitest bilan 3.0–3.3 s ketdi, bitta trivial test — 212 ms va 758 ms. Shuning uchun backend'da node:test qoldi: tezroq va 0 bog'liqlik.

Bu darsda

  • node --test fayllarni qanday topishini va ishga tushirishini tushuntirasiz.
  • describe/it, hook'lar, skip, todo, --test-name-pattern bilan ishlaysiz.
  • assert ning strict rejimini va eng kerakli tekshiruvlarini to'g'ri tanlaysiz.
  • Snapshot testni yozib, uni yangilashni bilasiz.
  • node:test va 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:

json
{
  "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-concurrency bilan 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):

js
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:

text
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.2241

Uchta kuzatuv:

  1. console.log lar natijalardan oldin chiqdi — reporter natijalarni oxirida tartib bilan chop etadi.
  2. beforeEach 4 marta ishladi: 3 ta test + todo. skip uchun hook ishlamaydi, todo uchun ishlaydi. Hujjatga ko'ra todo test bajariladi, lekin yiqilsa ham xato hisoblanmaydi; funksiyasiz todo esa bilan "o'tgan" bo'lib chiqdi.
  3. pass 3, skipped 1, todo 1 — jami 5. todo va skip CI'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/after baribir ishladi.
  • it.only(...) + node --test --test-only — faqat belgilanganlar. Bayroqsiz only ta'sir qilmaydi — commit'da unutib qoldirsangiz CI barcha testlarni yuritadi, bu yaxshi.
  • --test-skip-pattern — teskarisi.

Tekshirib ko'ring: Nega kanon har test faylida before da 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".

js
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:

text
✔ 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". equal havolani solishtiradi; obyekt uchun deepEqual kerak. Xabar o'zi maslahat beryapti.
  • massiv tartibi — deepEqual tartibga 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:

js
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:

text
to'rttasi ham o'tdi

throws 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:

js
test("xato", () => {
  assert.deepEqual(
    { matn: "Non", teglar: ["uy"] },
    { matn: "Non", teglar: ["Uy"] },
  );
});

Biz ishga tushirdik (izning at … qatorlari olib tashlandi):

text
✖ 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:

ts
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:

js
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):

  1. 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-snapshots bilan yarating".
  2. node --test --test-update-snapshots — o'tdi va yonida snap.test.mjs.snapshot fayli paydo bo'ldi:
text
exports[`404 javobi shakli 1`] = `
{
  "type": "about:blank",
  "title": "Not Found",
  "status": 404,
  "detail": "Vazifa 9 topilmadi"
}
`;
  1. Oddiy yurish — o'tdi.
  2. Kodda 9 ni 10 ga 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.

62 test: to'liq yurish vaqti (mediana)
  • 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.

js
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):

text
1 before
2 beforeEach
3 a
2 beforeEach
3 b
4 after

before — 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
js
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:

text
✔ qo'shish
✘ satr: Expected values to be strictly equal:
✔ async xato
o'tdi 2, yiqildi 1

Runner'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:test ga o'tmoqda — bog'liqliksiz CI tezroq va xavfsizroq.
  • Eski loyihalarda Jest va Mocha + Chai ko'p uchraydi. describe/it/before g'oyasi hamma joyda bir xil — o'tish asosan importlar (Jest).
  • CI: --test-reporter=junit yoki tap — GitHub Actions va boshqa tizimlar natijani jadval qilib ko'rsatadi (34-qism).
  • Intervyu savollari: "assert.equal va deepEqual farqi?", "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; .ts type 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 (await bilan), partialDeepStrictEqual; (haqiqiy, kutilgan) tartibi.
  • Snapshot: birinchi yurish yiqiladi, --test-update-snapshots faylni 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:test qoldi.

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-api holat 51 (package.json, test/).
Ulashish:Telegram'da

Izohlar (0)

Izoh yozish uchun kiring.

  • Hozircha izoh yo'q. Birinchi bo'ling!
node:test va node:assert: Node'ning o'rnatilgan test runner'i chuqur — IlmHamroh