कंपोनेंट (यूनिट) टेस्टिंग

यह क्यों ज़रूरी है

कई defects, जैसे गलत formula, छूटी हुई condition या handle न की गई खाली value, किसी एक component के अंदर ही होते हैं। जब component test ऐसा defect पकड़ता है, तो उसकी जगह तुरंत पता चल जाती है: fail होने वाला test function और input का नाम बता देता है। वही defect बाद में user interface से मिले, तो किसी को उसकी जगह पता चलने से पहले bug report, reproduction और कई layers में जाँच की ज़रूरत पड़ती है।

Tester के लिए component tests team की test strategy का पहला safety net हैं। ये क्या cover करते हैं, यह जानकर आप system और acceptance tests को उन चीज़ों पर लगा सकते हैं जिन्हें सिर्फ़ वही levels पकड़ सकते हैं, बजाय उन checks को दोहराने के जो हर commit पर पहले से चलते हैं। ये क्या cover नहीं कर सकते, यानी stubs और mocks के पीछे छिपा behaviour, यह जानकर पता चलता है कि integration risk कहाँ बाकी है।

Component test क्या है और उसे कौन लिखता है

ISTQB Foundation syllabus v4.0 के अनुसार component testing का focus components को isolation में टेस्ट करने पर होता है। इसके लिए अक्सर ख़ास support चाहिए, जैसे test harness या unit test framework, और इसे आम तौर पर developers अपने development environment में करते हैं। व्यवहार में यहाँ test basis वह material होता है जो code के सबसे क़रीब है: component का detailed design या specification, ख़ुद code और data model।

Component किसे माना जाए, यह code पर निर्भर है। Back end में यह आम तौर पर एक function या class होता है; front end में यह date picker जैसा एक अकेला UI component हो सकता है। Teams शब्दों का इस्तेमाल भी अलग-अलग करती हैं: कुछ "component test" किसी बड़ी चीज़ के लिए कहती हैं, जैसे एक पूरी service जिसके आस-पास की हर चीज़ बदल दी गई हो, इसलिए numbers की तुलना करने से पहले पूछें कि आपकी team का मतलब क्या है।

ज़्यादातर unit tests की बनावट तीन हिस्सों वाली होती है, जिसे अक्सर Arrange, Act, Assert कहा जाता है: inputs और dependencies तैयार करें, component को एक बार call करें, और result की तुलना expected value से करें। अच्छा unit test तेज़ होता है, एक behaviour जाँचता है, हर machine और हर run पर एक ही result देता है, और उसका नाम expected behaviour बताता है।

Isolation और test doubles: stubs, mocks और बाकी

असली components दूसरी चीज़ों पर निर्भर होते हैं: database, payment provider, आज की तारीख़, किसी दूसरी team की service। किसी एक component को isolation में टेस्ट करने के लिए developer इन dependencies को test doubles से बदल देता है। यह Gerard Meszaros का सामान्य term है, जिसका नाम फ़िल्मों के stunt double से आया है। Isolation test को तेज़ और repeatable बनाता है, और उन हालात को टेस्ट करने लायक बनाता है जिन्हें असली dependency के साथ पैदा करना मुश्किल है, जैसे timeout या expired coupon।

ISTQB glossary में दो पुराने terms हैं: stub उस component की जगह लेता है जिसे component under test call करता है, और driver component under test को उसके असली caller की जगह call करता है। Drivers और stubs मिलकर test harness बनाते हैं। नीचे के बारीक अंतर Meszaros से आते हैं, जैसा Martin Fowler ने समझाया है:

• Dummy: सिर्फ़ parameter list भरने के लिए pass किया जाता है; असल में कभी इस्तेमाल नहीं होता।
• Stub: test के दौरान होने वाली calls के तैयार जवाब देता है, जैसे "SAVE10 एक 10% coupon है"। फिर test component का result जाँचता है (state verification)।
• Spy: ऐसा stub जो यह भी record करता है कि उसे कैसे call किया गया, ताकि test बाद में calls जाँच सके।
• Mock: उन calls के साथ पहले से programmed होता है जिनकी वह उम्मीद करता है, और वे न हों तो test fail होता है, जैसे "ठीक एक confirmation e-mail भेजो" (behaviour verification)।
• Fake: काम करने वाला लेकिन सरल किया गया implementation, जैसे in-memory database।

आज़माएँ: Mock API रिस्पॉन्स जनरेटर आज़माएँ: Mock एरर रिस्पॉन्स जनरेटर

Worked example: stubbed service के साथ coupon component

Requirement: "Valid coupon basket के subtotal से अपना percentage घटाता है, coupon की maximum discount तक। Unknown या expired coupon subtotal को नहीं बदलता और invalid के रूप में report होता है।" Component applyCoupon code को couponApi के ज़रिए lookup करता है, जो production में एक remote coupon service को call करता है। नीचे का code पढ़ने के लिए JavaScript जानना ज़रूरी नहीं: await जवाब का इंतज़ार करता है, test(...) नाम वाला एक test define करता है, और expect(actual).toEqual(expected) actual result की तुलना expected result से करता है।

Tests में couponApi एक stub है जो सिर्फ़ एक coupon जानता है, SAVE10: 10% छूट, अधिकतम 50.00 SAR। अब results न असली service के चालू होने पर निर्भर हैं, न shared database में मौजूद coupons पर, न आज की तारीख़ पर। Developer हर rule के लिए एक test लिखता है, हर एक में requirement से निकाली गई expected value के साथ:

• SAVE10 के साथ 200.00 → total 180.00 (10% यानी 20.00, cap से कम)।
• SAVE10 के साथ 1000.00 → total 950.00 (10% यानी 100.00 होता, इसलिए 50.00 की cap लागू होती है)।
• ऐसा stub जो coupon को expired बताकर लौटाता है → total 200.00, error COUPON_INVALID।
• ऐसा stub जिसे code FAKE99 के लिए कुछ नहीं मिलता → total 200.00, error COUPON_INVALID।
• ऐसा stub जो "service unavailable" error फेंकता है → error applyCoupon से बाहर निकल जाता है। Requirement यह नहीं बताती कि तब checkout को क्या करना चाहिए, इसलिए tester यह सवाल product owner के पास ले जाता है। Double ने इस path को seconds में टेस्ट करने लायक बना दिया; असली service के साथ इसे जानबूझकर पैदा करना मुश्किल है।

// Component under test
async function applyCoupon(code, subtotal, couponApi) {
  const coupon = await couponApi.lookup(code);
  if (!coupon || coupon.expired) return { total: subtotal, error: 'COUPON_INVALID' };
  const discount = Math.min((subtotal * coupon.percent) / 100, coupon.maxDiscount);
  return { total: subtotal - discount, error: null };
}

// Arrange: a stub gives a canned answer instead of the remote coupon service
const couponApi = {
  lookup: async (code) =>
    code === 'SAVE10' ? { percent: 10, maxDiscount: 50, expired: false } : null,
};

test('SAVE10 takes 10% off a 200.00 basket', async () => {
  const result = await applyCoupon('SAVE10', 200, couponApi);  // Act
  expect(result).toEqual({ total: 180, error: null });          // Assert
});

Test-driven development: पहले test

ISTQB syllabus test-driven development (TDD) को, acceptance test-driven development (ATDD) और behaviour-driven development (BDD) के साथ, उन approaches में गिनता है जिनमें tests development को दिशा देते हैं। TDD में developer छोटे cycles में काम करता है: behaviour के अगले छोटे हिस्से के लिए component test लिखता है और उसे fail होते देखता है, उसे pass कराने लायक बस उतना code लिखता है, फिर सारे tests green रखते हुए code की structure सुधारता है। Practitioners इस cycle को red, green, refactor कहते हैं।

Coupon example में developer पहले 180.00 वाला test एक ऐसे function के लिए लिखेगा जो अभी मौजूद ही नहीं, फिर cap वाला test, फिर expired coupon वाला, और हर test को pass कराने लायक ही code जोड़ेगा। TDD पीछे तेज़ regression tests का एक suite छोड़ता है और design को छोटे, आसानी से isolate होने वाले components की ओर ले जाता है। यह development का एक तरीका है जो early testing लागू करता है; यह दूसरे test levels की जगह नहीं लेता, क्योंकि developer के tests requirement की सिर्फ़ developer की अपनी समझ को जाँच सकते हैं।

Tester को क्या जानना और review करना चाहिए

Unit tests शायद ही कभी tester के ज़िम्मे होते हैं, लेकिन उन्हें पढ़ना team के सबसे सस्ते reviews में से एक है। अच्छे सवाल पूछने के लिए ख़ुद code लिखना ज़रूरी नहीं; tests के नाम और inputs आम तौर पर बता देते हैं कि क्या जाँचा गया। इन चीज़ों को देखें:

• Rules: हर acceptance criterion को किसी test से जोड़ें। जिस rule का कोई test नहीं, जैसे कोई cap या default value, वह इस level पर एक gap है।
• Inputs: खाली values, शून्य, requirement में लिखी exact limit और invalid formats, सिर्फ़ एक typical value नहीं।
• Assertions: हर test result की तुलना requirement से निकाली गई value से करता है, code के output से copy की गई value से नहीं, और सिर्फ़ "कोई error नहीं आया" से भी नहीं।
• Doubles: stubs वही लौटाते हैं जो असली dependency सच में लौटाती है, उसके errors और खाली results समेत। बाद में integration tests और contract tests (जो जाँचते हैं कि असली service अब भी वैसे ही जवाब देती है जैसा doubles मानते हैं) पुष्टि करते हैं कि दोनों मेल खाते हैं।
• Independence: run order, असली clock, random values या shared data पर कोई निर्भरता नहीं। जो test code बदले बिना कभी pass और कभी fail हो, वह flaky है।
• Results: जानें कि हर build की unit test report कहाँ है; जिस build के unit tests fail हुए या skip किए गए, वह system testing के लिए तैयार नहीं है।

आज़माएँ: Requirements → टेस्ट केस आज़माएँ: बाउंड्री वैल्यू जनरेटर

अक्सर पूछे जाने वाले सवाल

संदर्भ

• ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
• ISTQB GlossaryISTQBटेस्टिंग शब्दों की मानक परिभाषाएँ — टेस्ट केस, रिग्रेशन टेस्टिंग, सेवेरिटी, प्रायोरिटी, बाउंड्री वैल्यू एनालिसिस आदि।
• Test Double (Martin Fowler)martinfowler.com · 2006test doubles के लिए Gerard Meszaros की शब्दावली — dummy, fake, stub, spy और mock — जैसा Martin Fowler ने सारांशित किया।
• Mocks Aren't Stubs (Martin Fowler)martinfowler.com · 2007state verification और behavior verification का अंतर, और test-driven development की classical और mockist शैलियों का अंतर।