हम यह सुनिश्चित करने के लिए इकाई परीक्षण का उपयोग करते हैं कि कोडबेस के अलग-अलग घटक काम करते हैं जैसा कि हम उनसे उम्मीद करते हैं।

यहां एक समान तकनीक स्टैक के साथ यूनिट परीक्षण के लिए एक अच्छा, त्वरित परिचय है, और यहां गहराई से व्याख्या दी गयी है।

रेपो रूट में, अपने टर्मिनल में निम्न कमांड का उपयोग करें

$ npm test

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

परीक्षण चलाने के बाद एक सारांश मुद्रित किया जाता है, और आप किसी भी वेब ब्राउज़र में coverage/index.html पर विस्तृत रिपोर्ट देख सकते हैं। आप अपने डिफॉल्ट वेब ब्राउज़र में पेज खोलने के लिए Mac पर कमांड लाइन से open coverage/index.html चला सकते हैं। आप कमांड का उपयोग करके टर्मिनल में परीक्षण चलाने के बाद कवरेज रिपोर्ट भी देख सकते हैं npx nyc report --reporter=text.

एकल परीक्षण या परीक्षणों के समूह को चलाने के लिए,.only सुइट में या तो .js फ़ाइल में परीक्षण करें और उपरोक्त आदेश का उपयोग करके परीक्षण चलाएं। सावधान रहो, हालांकि आप प्रतिबद्ध नहीं हैं। .only (हम हमेशा चाहते हैं कि हमारा CI सभी यूनिट टेस्ट चलाए।)

केवल "p5.ColorConversion" परीक्षणों का सूट चलाने के लिए, आप पढ़ने के लिए test/unit/color/color_conversion.js की पहली पंक्ति को बदल देंगे-

suite.only('color/p5.ColorConversion', function() {

अब जब आप npm test का उपयोग करते हैं, तो केवल उस function() बॉडी के भीतर परीक्षण चलाए जाएंगे।

यह सुविधा .only () का विलोम है। .Skip () को जोड़कर, आप मोचा को इन सुइट्स और टेस्ट केस (मामलों) को अनदेखा करने के लिए कह सकते हैं। कुछ भी छोड़ दिया जाना लंबित के रूप में चिह्नित किया जाएगा, और इस तरह की रिपोर्ट की जाएगी।

हम अपने यूनिट परीक्षणों को संरचित करने और चलाने के लिए Mocha का उपयोग करते हैं हम कोड का व्यवहार कैसे करना चाहिए, इसके बारे में अलग-अलग कथन लिखने के लिए हम [chai assert (और except)](https://www.chaijs.com api/assert/) का उपयोग करते हैं।

हमारे पास test/unit फ़ोल्डर के तहत परीक्षण का एक संग्रह है जो ब्राउज़र में चलता है और test/node के तहत परीक्षणों का एक संग्रह है जो नोड्स .js. में चलता है।

ब्राउज़र परीक्षण हेडलेस क्रोम में चलते हैं। यही कारण है कि जब आप परीक्षण चलाते हैं तो आपको ब्राउज़र विंडो पॉप-अप नहीं दिखाई देती है।

ये वर्तमान में केवल ब्राउज़र परीक्षणों के लिए उपलब्ध हैं (जहाँ हमारे अधिकांश परीक्षण चलते हैं)-

• test/js/mocha_setup.js मोचा के लिए कुछ विकल्प कॉन्फ़िगर करता है।
• test/js/chai_helpers.js chai.assert में चाई स्थापित करता है और कुछ उपयोगी कार्यों को जोड़ता है।
• test/js/p5_helpers.js p5 स्केच के परीक्षण के लिए कुछ सहायकों को जोड़ता है।

Node.js परीक्षणों के लिए सेटअप सभी test/mocha.opts में किया जाता है।

जब आप p5.js रेपो में एक पुल अनुरोध भेजते हैं, तो यह स्वचालित रूप से परीक्षण चलाएगा। इससे हमें यह जांचने में मदद मिलती है कि परीक्षण प्रत्येक पुल अनुरोध के लिए गुजरता है, व्यक्तिगत योगदानकर्ताओं से कोई अतिरिक्त काम नहीं है। यह स्वतः ही कोडेकोव रिपोर्ट को कवरेज रिपोर्ट भी अपलोड कर देता है।

यदि आप अधिक इकाई परीक्षण जोड़ना चाहते हैं, तो देखें और देखें कि क्या उस घटक के लिए पहले से ही एक परीक्षण फ़ाइल है जिसके लिए आप परीक्षण जोड़ना चाहते हैं। आम तौर पर, src में दिए गए फ़ाइल के लिए test/unit के तहत एक ही रास्ते पर होते हैं। (उदाहरण के लिए src/color/p5.Color.js के लिए परीक्षण test/unit/color/p5.Color.js में हैं।)

यदि आपको एक नहीं मिल रहा है, तो शायद इसलिए कि उस फ़ाइल के लिए कोई परीक्षण नहीं हुआ है (अभी तक पलक), इसलिए ऊपर दिए गए सम्मेलनों के अनुसार एक नई फ़ाइल बनाएं। यदि आप जिस मॉड्यूल का परीक्षण कर रहे हैं, उसे काम करने के लिए ब्राउज़र की आवश्यकता होती है, तो आप इसे test/unit में रखना चाहते हैं, लेकिन यदि ऐसा नहीं है, तो आप इसे test/node के तहत जोड़ना चाह सकते हैं। जब संदेह हो, तो test/unit में एक ब्राउज़र टेस्ट जोड़ने के लिए डिफ़ॉल्ट! (यदि हमें ज़रूरत है तो बाद में स्थानांतरित करना बहुत आसान है।)

यदि आपको test/unit के लिए मॉड्यूल के लिए एक परीक्षण फ़ाइल को जोड़ना है, तो आपको test/unit/spec.js में युक्ति के लिए परीक्षण के तहत मॉड्यूल की भी आवश्यकता होगी। यह सुनिश्चित करेगा कि आपके परीक्षण को चलाने के लिए आवश्यक मॉड्यूल लोड किए गए हैं। आप इन परीक्षणों को ब्राउज़र में test/test.html फ़ाइल देखकर देख सकते हैं।

एक इकाई चुनें, यह परीक्षण करने के लिए एक विधि या एक चर हो सकता है। एक उदाहरण के रूप में p5.prototype.isKeyPressed का उपयोग करें। परीक्षण लिखने की शुरुआत करने से पहले, हमें इस पद्धति के अपेक्षित व्यवहार को समझने की आवश्यकता है। अपेक्षित व्यवहार: बूलियन सिस्टम वैरिएबल सही होना चाहिए यदि कोई कुंजी दबाया जाता है और गलत है यदि कोई कुंजी दबाया नहीं जाता है। अब आप इस अपेक्षित व्यवहार के खिलाफ विभिन्न परीक्षणों के बारे में सोच सकते हैं। संभावित परीक्षण मामले हो सकते हैं-

• वेरिएबल एक बूलियन है।
• यह सच होना चाहिए अगर एक कुंजी को दबाया जाता है।
• यह सच होना चाहिए अगर एक कुंजी को दबाया जाता है - वर्णमाला कुंजी, संख्या कुंजी, विशेष कुंजी आदि।
• यदि कई कुंजियों को दबाया जाए तो यह सही होना चाहिए।
• यह गलत होना चाहिए अगर कोई कुंजी दबाया नहीं जाता है।
• यदि आप अधिक के बारे में सोच सकते हैं, तो आगे बढ़ें और उनके लिए परीक्षण जोड़ें।

हम p5.prototype.isKeyPressed के लिए एक परीक्षण सूट बना सकते हैं और इसके लिए परीक्षण बनाना शुरू कर सकते हैं। हम अपने यूनिट परीक्षणों की संरचना के लिए Mocha का उपयोग करेंगे।

suite('p5.prototype.keyIsPressed', function() {
  test('keyIsPressed is a boolean', function() {
    //परीक्षण यहाँ लिखें
  });

  test('keyIsPressed is true on key press', function() {
    //परीक्षण यहाँ लिखें
  });

  test('keyIsPressed is false when no keys are pressed', function() {
    //परीक्षण यहाँ लिखें
  });
});

हमने परीक्षणों की संरचना की है, लेकिन हमने अभी तक परीक्षण नहीं लिखे हैं। हम इसके लिए ची के दावे का उपयोग करेंगे। निम्नलिखित को धयान मे रखते हुए-

test('keyIsPressed is a boolean', function() {
  assert.isBoolean(myp5.keyIsPressed); //दावा करता है कि मूल्य एक बूलियन है।
});

इसी प्रकार हम assert.strictEqual(myp5.keyIsPressed, true) का उपयोग कर सकते हैं यदि मान सत्य है। आप यहां चाय के दावे के बारे में अधिक पढ़ सकते हैं। अब जब आप परीक्षण लिख चुके हैं, तो उन्हें चलाएं और देखें कि क्या विधि अपेक्षित रूप से व्यवहार करती है। यदि नहीं, तो उसी के लिए एक मुद्दा बनाएं और यदि आप चाहें, तो आप इसे ठीक करने पर भी काम कर सकते हैं।