कारोबार के टूल

मूल रूप से, अपने-आप होने वाली जांच में सिर्फ़ कोड होते हैं. इन्हें इस्तेमाल करने पर गड़बड़ी हो सकती है या गड़बड़ी हो सकती है कुछ गलत हुआ. ज़्यादातर लाइब्रेरी या टेस्टिंग फ़्रेमवर्क अलग-अलग तरह की जिनसे टेस्ट को लिखना आसान हो जाता है.

जैसा कि पिछले सेक्शन में बताया गया है, इन प्रिमिटिव में आम तौर पर इंडिपेंडेंट टेस्ट (जिन्हें टेस्ट केस कहा जाता है) को परिभाषित करने और दावे. दावा, नतीजे की जांच करने और नतीजे को फेंकने में कोई गड़बड़ी होती है और उसे सभी का बेसिक प्रिमिटिव माना जा सकता है परीक्षण प्रिमिटिव.

इस पेज में इन नियमों के बारे में सामान्य जानकारी दी गई है. आपका चुना गया फ़्रेमवर्क शायद ऐसा कुछ है, लेकिन यह सटीक रेफ़रंस नहीं है.

उदाहरण के लिए:

import { fibonacci, catalan } from '../src/math.js';
import { assert, test, suite } from 'a-made-up-testing-library';

suite('math tests', () => {
  test('fibonacci function', () => {
    // check expected fibonacci numbers against our known actual values
    // with an explanation if the values don't match
    assert.equal(fibonacci(0), 0, 'Invalid 0th fibonacci result');
    assert.equal(fibonacci(13), 233, 'Invalid 13th fibonacci result');
  });
  test('relationship between sequences', () => {
    // catalan numbers are greater than fibonacci numbers (but not equal)
    assert.isAbove(catalan(4), fibonacci(4));
  });
  test('bugfix: check bug #4141', () => {
    assert.isFinite(fibonacci(0)); // fibonacci(0) was returning NaN
  })
});

यह उदाहरण "गणित" नाम के टेस्ट का एक ग्रुप बनाता है. इसे कभी-कभी सुइट भी कहा जाता है टेस्ट" के साथ मिलकर, तीन ऐसे स्वतंत्र टेस्ट केस को परिभाषित करता है जिनमें से हर एक ने कुछ दावे किए हैं. इन टेस्ट केस को आम तौर पर, अलग-अलग हल किया जा सकता है या चलाया जा सकता है. उदाहरण के लिए, फ़िल्टर फ़्लैग जोड़ सकता है.

प्रिमिटिव के तौर पर दावा करने में मदद करने वाले

Vitest के साथ-साथ ज़्यादातर टेस्टिंग फ़्रेमवर्क में दावों का कलेक्शन शामिल होता है assert ऑब्जेक्ट पर हेल्पर का इस्तेमाल करना, जिसकी मदद से रिटर्न वैल्यू की तुरंत जांच की जा सकती है या कुछ उम्मीद के उलट अन्य स्थितियां. ऐसी उम्मीद अक्सर "अच्छी" होती है वैल्यू. पिछले उदाहरण में, हम जानते हैं कि 13वीं फिबोनाशी संख्या 233 है, ताकि हम सीधे assert.equal का इस्तेमाल करके इसकी पुष्टि कर सकें.

आपको यह उम्मीद भी हो सकती है कि कोई वैल्यू किसी खास फ़ॉर्मैट में होगी या आपके पास किसी दूसरी वैल्यू से ज़्यादा है या कोई दूसरी प्रॉपर्टी होनी चाहिए. इस कोर्स पर ये काम नहीं किए जाएंगे इसमें दावा करने में मदद करने वाले सभी संभावित लोगों के बारे में बताया गया है, लेकिन टेस्ट फ़्रेमवर्क हमेशा कम से कम इन बुनियादी जांचों से जुड़ा डेटा दें:

  • एक 'सच' चेक, अक्सर 'ठीक' के रूप में बताया जाता है जांच करता है कि कोई शर्त सही है या नहीं. कैसे मिलान करते हुए आप एक if लिख सकते हैं जो यह देखता है कि कुछ सफल हुआ या नहीं या सही है. आम तौर पर, यह assert(...) या assert.ok(...) के तौर पर दिया जाता है और एक मान और एक वैकल्पिक टिप्पणी को शामिल करता है.

  • समानता की जाँच, जैसे कि गणित की जाँच का उदाहरण, जिसमें आप किसी ज्ञात अच्छे मूल्य के बराबर किसी ऑब्जेक्ट का रिटर्न मान या स्थिति. ये इसके लिए हैं प्रिमिटिव इक्वलिटी (जैसे कि संख्याओं और स्ट्रिंग के लिए) या रेफ़रेंशियल इक्वलिटी (क्या ये एक ही वस्तु हैं). हुड के तहत ये बस एक 'सच' है सही का निशान लगाएं == या === की तुलना के साथ.

    • JavaScript, ढीली (==) और सख्त (===) समानता के बीच अंतर करता है. ज़्यादातर टेस्ट लाइब्रेरी में, आपको assert.equal और assert.strictEqual.
  • बेहतर बराबरी की जांच, जिसमें 'बराबर है' की जांच शामिल है. ऑब्जेक्ट, सरणियों, और अन्य जटिल डेटा टाइप के कॉन्टेंट के साथ-साथ इंटरनल लॉजिक का इस्तेमाल करके, ऑब्जेक्ट को ट्रैवर्स कर उनकी तुलना करना. ये ज़रूरी हैं क्योंकि JavaScript में ऐसी कोई सामग्री मौजूद नहीं है, जिससे दो ऑब्जेक्ट या अरे. उदाहरण के लिए, [1,2,3] == [1,2,3] हमेशा गलत होता है. जांच करें फ़्रेमवर्क में अक्सर deepEqual या deepStrictEqual हेल्पर शामिल होते हैं.

दावा करने में मदद करने वाले ऐसे लोग जो दो वैल्यू की तुलना करते हैं (न कि सिर्फ़ 'ट्रुथ' चेक को) आम तौर पर दो या तीन तर्क लेते हैं:

  • परीक्षण किए जा रहे कोड से जनरेट की गई वास्तविक वैल्यू या की जांच करनी होगी.
  • अनुमानित वैल्यू, आम तौर पर हार्ड कोड की गई होती है (उदाहरण के लिए, कोई लिटरल संख्या या स्ट्रिंग).
  • एक वैकल्पिक टिप्पणी, जिसमें यह बताया गया हो कि किस तरह के काम की उम्मीद है या क्या नहीं हो सकता है, जिसे लाइन के फ़ेल होने पर शामिल किया जाएगा.

अलग-अलग तरह के जांच करता है, क्योंकि यह बहुत कम है कि कोई व्यक्ति आपके स्थिति की सही वह भी अपने काम आ रहा है. उदाहरण के लिए:

  test('JWT parse', () => {
    const json = decodeJwt('eyJieSI6InNhbXRob3Ii');

    assert.ok(json.payload.admin, 'user should be admin');
    assert.deepEqual(json.payload.groups, ['role:Admin', 'role:Submitter']);
    assert.equal(json.header.alg, 'RS265')
    assert.isAbove(json.payload.exp, +new Date(), 'expiry must be in future')
  });

Vitest में चाय दावे की लाइब्रेरी का इस्तेमाल किया गया है अपने सहयोगी संगठनों को इसके संदर्भ देखें.

धाराप्रवाह और BDD दावे

कुछ डेवलपर दावा करने की ऐसी स्टाइल पसंद करते हैं जिसे व्यवहार-आधारित कहा जा सकता है डेवलपमेंट (बीडीडी) या पूरी तरह कुशल-स्टाइल दावे. इन्हें "Expect" भी कहा जाता है सहायकों, क्योंकि वह एंट्री पॉइंट जो उम्मीदों की जांच करना expect() नाम का एक तरीका है.

यह तय करने के लिए कि सहायता करने वाले लोग, आसान तरीके से किए गए दावों की तरह ही कैसे व्यवहार करते हैं assert.ok या assert.strictDeepEquals जैसे कॉल स्वीकार करते हैं, लेकिन कुछ डेवलपर को ये ज़्यादा आसानी से समझ आती हैं. BDD दावा ऐसा पढ़ सकता है:

// A failure here would generate "Expect result to be an array that does include 42"
const result = await possibleMeaningsOfLife();
expect(result).to.be.an('array').that.does.include(42);

// or a simpler form
expect(result).toBe('array').toContainEqual(42);

// the same in assert might be
assert.typeOf(result, 'array', 'Expected the result to be an array');
assert.include(result, 42, 'Expected the result to include 42');

दावे की यह शैली मेथड चेनिंग नाम की तकनीक की वजह से काम करती है. जहां expect से लौटाया गया ऑब्जेक्ट, कॉल कैसे किया जाता है. कॉल के कुछ हिस्से, जिनमें to.be और that.does शामिल हैं ऊपर दिए गए उदाहरण में, इनका कोई फ़ंक्शन नहीं है और उन्हें सिर्फ़ कॉल करने के लिए शामिल किया गया है अगर हमारे टेस्ट में शामिल है, तो उसे पढ़ना आसान हो जाता है. साथ ही, अगर विफल. (ध्यान देने वाली बात यह है कि आम तौर पर, expect में वैकल्पिक टिप्पणी नहीं की जा सकती, क्योंकि चेन में उस गड़बड़ी के बारे में साफ़ तौर पर बताया जाना चाहिए.)

कई टेस्ट फ़्रेमवर्क, Fluent/BDD और सामान्य दावे, दोनों के साथ काम करते हैं. वाइटेस्ट उदाहरण के लिए, दोनों फ़ॉर्मैट में इस तरह का कॉन्टेंट एक्सपोर्ट किया जाता है चाई का काम है और BDD को लेकर इसका अपना एक छोटा सा तरीका है. जेस्ट दूसरी ओर, केवल एक अभाव की संभावना होती है तरीका डिफ़ॉल्ट रूप से सेट हो जाता है.

सभी फ़ाइलों में ग्रुप टेस्ट

टेस्ट लिखते समय, हम पहले से ही इंप्लिसिट ग्रुपिंग देने की कोशिश करते हैं—इसके बजाय सभी टेस्ट एक फ़ाइल में होने की तुलना में, एक से ज़्यादा टेस्ट को लिखना आम बात है फ़ाइलें शामिल हैं. आम तौर पर, टेस्ट रनर को आम तौर पर यह पता होता है कि कोई फ़ाइल टेस्ट के लिए है, क्योंकि का इस्तेमाल किया जा सकता है. उदाहरण के लिए, जांच में सभी शामिल हैं. आपके प्रोजेक्ट की वे फ़ाइलें जो ".test.jsx" जैसे एक्सटेंशन पर खत्म होती हैं या ".spec.ts" (".test" और ".spec" के साथ-साथ कई मान्य एक्सटेंशन).

कॉम्पोनेंट की जांच, टेस्ट में शामिल कॉम्पोनेंट के लिए पीयर फ़ाइल में की जाती है, जैसा कि नीचे दी गई डायरेक्ट्री में बताया गया है:

में फ़ाइलों की सूची
  डायरेक्ट्री, जिसमें UserList.tsx और UserList.test.tsx शामिल है.
कॉम्पोनेंट फ़ाइल और उससे जुड़ी टेस्ट फ़ाइल.

इसी तरह, यूनिट टेस्ट को टेस्ट में कोड के बगल में रखा जाता है. एंड-टू-एंड टेस्ट, दोनों अपनी खुद की फ़ाइल में हो सकते हैं. साथ ही, इंटिग्रेशन की पूरी जांच भी हो सकती है उन्हें अपने खास फ़ोल्डर में रख सकते हैं. ये स्ट्रक्चर तब मददगार हो सकते हैं, जब टेस्ट केस बड़ा हो जाता है और उसके लिए उसे टेस्ट नहीं करने वाली फ़ाइलों की ज़रूरत पड़ती है. उदाहरण के लिए, का इस्तेमाल करने की अनुमति दें.

फ़ाइलों के अंदर ग्रुप टेस्ट

जैसा कि पहले के उदाहरणों में बताया गया है, टेस्ट को suite(), जो उन टेस्ट का ग्रुप बनाता है जिन्हें आपने test() के साथ सेट अप किया है. आम तौर पर, सुइट लेकिन वे मिलते-जुलते टेस्ट का ग्रुप बनाकर, स्ट्रक्चर तैयार करने में मदद करते हैं या लक्ष्यों को हासिल करने का तरीका जानें. test() के लिए, स्वीकार किया गया तरीका यह जानकारी देता है खुद टेस्ट की कार्रवाइयों को पूरा करता है.

दावों के साथ, Fluent/BDD में इसके लिए काफ़ी मानक समतुल्य है ग्रुप बनाने की सुविधा का इस्तेमाल करें. कुछ सामान्य उदाहरणों की तुलना इस कोड में की गई है:

// traditional/TDD
suite('math tests', () => {
  test('handle zero values', () => {
    assert.equal(fibonacci(0), 0);
  });
});

// Fluent/BDD
describe('math tests', () => {
  it('should handle zero values', () => {
    expect(fibonacci(0)).toBe(0);
  });
})

ज़्यादातर फ़्रेमवर्क में, suite और describe उसी तरह काम करते हैं जैसे test और it, expect और assert के इस्तेमाल में ज़्यादा अंतर के उलट दावा करने के लिए.

दूसरे टूल में सुइट और टेस्ट व्यवस्थित करने का तरीका काफ़ी अलग होता है. इसके लिए उदाहरण के लिए, Node.js में पहले से मौजूद टेस्ट रनर, test() को नेस्टिंग कॉल की सुविधा देता है, ताकि सीधे तौर पर टेस्ट हैरारकी बनाएं. हालांकि, Vitest में सिर्फ़ इस तरह की suite() का इस्तेमाल करके नेस्ट किया जा रहा है. साथ ही, दूसरे test() में तय किए गए test() को नहीं चलाया जाएगा.

दावों की तरह ही, याद रखें कि ग्रुपिंग का जिन तरीकों का इस्तेमाल आपके टेक्नोलॉजी स्टैक ने किया है, क्या वह ज़रूरी नहीं है. इस कोर्स में कवर किया जाएगा देख सकते हैं, लेकिन आपको यह पता लगाना होगा कि वे आपकी का विकल्प चुनने के लिए टूल चुनें.

लाइफ़साइकल के तरीके

अपने टेस्ट को ग्रुप करने की एक वजह, भले ही आप टेस्ट के टॉप लेवल पर हों फ़ाइल है, जो हर जांच के लिए या एक बार चलने वाली सेटअप और टियरडाउन विधियां उपलब्ध कराती है कई टेस्ट किए जा सकते हैं. ज़्यादातर फ़्रेमवर्क में चार तरीके होते हैं:

हर `test()` या `it()` के लिए सुइट के लिए एक बार
जांच करने से पहले `beforebefore()` `beforeAll()`
जांच करने के बाद `Aftereach()` `AfterAll()`

उदाहरण के लिए, हो सकता है कि आप प्रत्येक से पहले एक वर्चुअल उपयोगकर्ता डेटाबेस को की जांच कर सकते हैं, और बाद में इसे हटा सकते हैं:

suite('user test', () => {
  beforeEach(() => {
    insertFakeUser('bob@example.com', 'hunter2');
  });
  afterEach(() => {
    clearAllUsers();
  });

  test('bob can login', async () => {  });
  test('alice can message bob', async () => {  });
});

यह टेस्ट को आसान बनाने में मददगार हो सकता है. आपके पास सामान्य सेटअप शेयर करने और टियरडाउन कोड का इस्तेमाल करें. इसके अलावा, अगर सेटअप और टियरडाउन कोड में खुद ही एक गड़बड़ी होती है, जो वे समस्याएं जिनमें खुद को टेस्ट में सफल न होने की वजह से शामिल न किया गया हो.

सामान्य सलाह

जब इन प्रिमिटिव के बारे में सोचते समय याद रखने के लिए यहां कुछ सुझाव दिए गए हैं.

प्रिमिटिव, गाइड के तौर पर काम करते हैं

ध्यान रखें कि यहां और अगले कुछ पेजों में उपलब्ध टूल और प्रिमिटिव Vitest, Jest, या Mocha या Web Test रनर या किसी अन्य से पूरी तरह से मेल खाता है एक खास फ़्रेमवर्क का इस्तेमाल किया जा सकता है. हमने Vitest को सामान्य गाइड के तौर पर इस्तेमाल किया है. इसलिए, मैप करना न भूलें उन्हें अपनी पसंद के फ़्रेमवर्क के मुताबिक बना सकते हैं.

ज़रूरत के हिसाब से दावे और मैच करें

टेस्ट बुनियादी रूप से कोड होते हैं, जिनसे गड़बड़ियां हो सकती हैं. हर दौड़ लगाने वाले को प्रिमिटिव, संभावित रूप से test(), अलग-अलग टेस्ट केस के बारे में बताने के लिए.

वहीं, अगर वह रनर assert(), expect(), और दावे को सपोर्ट करने वाला भी है, याद रखें कि यह हिस्सा सुविधा के बारे में है और अगर . ऐसे किसी भी कोड को चलाया जा सकता है जिससे गड़बड़ी हो सकती है. इनमें अन्य कोड भी शामिल हैं दावा लाइब्रेरी या पुराने ज़माने वाला if स्टेटमेंट.

IDE को सेट अप करना, बैटरी लाइफ़ बचाने में मदद कर सकता है

पक्का करना कि आपके IDE जैसे VSCode के पास, अपने-आप पूरे होने की सुविधा का ऐक्सेस है और आपके चुने हुए परीक्षण टूल के दस्तावेज़ आपको और ज़्यादा उत्पादक बना सकते हैं. इसके लिए उदाहरण के लिए, चाई के दावे में assert पर 100 से ज़्यादा तरीके हैं लाइब्रेरी और दाईं ओर वाला इनलाइन दिखाना आसान हो सकता है.

यह खास तौर पर उन टेस्ट फ़्रेमवर्क के लिए ज़रूरी हो सकता है जो ग्लोबल नेमस्पेस का इस्तेमाल करें. यह थोड़ा-बहुत अंतर है, लेकिन टेस्टिंग लाइब्रेरी का इस्तेमाल अक्सर इंपोर्ट किए बिना किया जा सकता है, अगर वे ग्लोबल नेमस्पेस में अपने-आप जोड़ दिया जाएगा:

// some.test.js
test('using test as a global', () => {  });

हम हेल्पर को इंपोर्ट करने का सुझाव देते हैं, भले ही वे अपने-आप काम करते हों, क्योंकि इससे आपके IDE को इन तरीकों को समझने का आसान तरीका मिल जाता है. (आपके पास हो सकता है React बनाते समय इस समस्या का सामना करना पड़ा, क्योंकि कुछ कोडबेस में React वैश्विक है, लेकिन कुछ में मौजूद नहीं है और उसे इसका उपयोग करके सभी फ़ाइलों में आयात करने की आवश्यकता होती है React.)

// some.test.js
import { test } from 'vitest';
test('using test as an import', () => {  });