टेस्टिंग क्या है

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

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

वेब पर व्यवहार के कुछ ऐसे उदाहरण जिनकी जांच की जा सकती है:

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

ऑटोमेटेड बनाम मैन्युअल तरीके से की जाने वाली जांच

आप अपने सॉफ़्टवेयर की जांच दो आम तरीकों से कर सकते हैं: अपने-आप होने वाली जांच और मैन्युअल तरीके से जांच करना.

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

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

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

एक उदाहरण की मदद से बुनियादी बातों के बारे में जानें

हमारे लिए, JavaScript या इससे जुड़ी भाषाएं लिखने वाले वेब डेवलपर के तौर पर, एक छोटा ऑटोमेटेड टेस्ट एक ऐसी स्क्रिप्ट हो सकती है जिसे आप रोज़ चलाते हैं. उदाहरण के लिए, नोड की मदद से या उसे ब्राउज़र में लोड करके:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

इस उदाहरण में, नीचे दी गई इनसाइट दी गई हैं:

• यह एक टेस्ट है, क्योंकि यह कुछ सॉफ़्टवेयर (Fibonacci फ़ंक्शन) चलाता है. साथ ही, यह पक्का करता है कि यह उम्मीद के मुताबिक वैल्यू के मुकाबले नतीजों की जांच करके, काम करता है या नहीं. अगर व्यवहार सही नहीं है, तो इससे गड़बड़ी होती है. JavaScript यह गड़बड़ी Error को फेंककर दिखाता है.

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

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

लाइब्रेरी की जांच की जा रही है

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

दावे, किसी नतीजे की जांच करने और कुछ गलत होने पर गड़बड़ी पैदा करने का एक तरीका है. उदाहरण के लिए, assert का इस्तेमाल करके, पिछले टेस्ट को कम शब्दों में लिखा जा सकता है:

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

इस जांच को और बेहतर बनाने के लिए, अलग-अलग टेस्ट तय करें. हालांकि, ऐसा करना ज़रूरी नहीं है और इन्हें सुइट में बांटा जा सकता है. यह सुइट, Fibonacci फ़ंक्शन और Catalan फ़ंक्शन की अलग-अलग जांच करता है:

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

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

सॉफ़्टवेयर की जांच करने के इस मामले में, संज्ञा के तौर पर test का मतलब टेस्ट केस से है: यह एक सिंगल, स्वतंत्र, और ठीक करने लायक स्थिति होती है, जैसे कि पिछले उदाहरण में "सीक्वेंस के बीच का संबंध" टेस्ट केस.

अलग-अलग नाम वाले टेस्ट, इन कामों के साथ-साथ अन्य कामों के लिए भी काम के होते हैं:

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

टेस्ट केस को समझने का एक तरीका यह है कि यूनिट टेस्टिंग के "थ्री A" का इस्तेमाल किया जाए: व्यवस्थित करें, कार्रवाई करें, और ज़ोर से दावा करें. हर टेस्ट केस के मुख्य हिस्से में ये चीज़ें शामिल होंगी:

• कुछ वैल्यू या स्थिति व्यवस्थित करें (यह सिर्फ़ हार्ड कोड किया गया इनपुट डेटा हो सकता है).
• कोई कार्रवाई करें, जैसे कि किसी तरीके को कॉल करना.
• assert का इस्तेमाल करके, आउटपुट वैल्यू या अपडेट की गई स्थिति का दावा करें.

टेस्ट का स्केल

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

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

अलग-अलग टेस्ट का स्केल इसे एक ऐसे सिद्धांत के अंदर रख सकता है जिसे अक्सर "टेस्टिंग पिरामिड" कहा जाता है. यह इस बात का अच्छा नियम हो सकता है कि टेस्ट की जांच कैसे की जाती है और वह कैसे चलता है.

यह आइडिया बार-बार अपनाया जाता रहा है और कई दूसरे आकार अब लोकप्रिय हो गए हैं, जैसे कि टेस्टिंग डायमंड या टेस्टिंग आइस कोन. शायद आपकी टेस्ट-राइटिंग प्राथमिकताएं आपके कोडबेस के लिए खास होंगी. हालांकि, एक सामान्य सुविधा यह है कि यूनिट टेस्ट जैसे आसान टेस्ट तेज़ी से चलाए जाते हैं, लिखने में आसान होते हैं (इसलिए, आपके पास इनमें से ज़्यादा होंगे), और सीमित दायरे की जांच होती है. वहीं, एंड-टू-एंड टेस्ट जैसे मुश्किल टेस्ट में लिखना मुश्किल होता है, लेकिन वे बड़े दायरे की जांच कर सकते हैं. असल में, कई टेस्टिंग 'आकारों' की सबसे ऊपर वाली लेयर मैन्युअल तरीके से टेस्ट की जाती है, क्योंकि कुछ लोगों के इंटरैक्शन को ऑटोमेटेड टेस्ट में शामिल करना बहुत मुश्किल होता है.

इन टाइप को अपने-आप होने वाली जांच के टाइप में शामिल किया जाएगा.

जांचें कि आपको कितना समझ आया