Java Language
इकाई का परीक्षण

परिचय

टिप्पणियों

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

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

यूनिट परीक्षण यह सुनिश्चित कर रहा है कि एक दिया गया मॉड्यूल अपेक्षित रूप से व्यवहार करता है। बड़े पैमाने पर अनुप्रयोगों में, वैक्यूम में मॉड्यूल के उचित निष्पादन को सुनिश्चित करना आवेदन की निष्ठा को सुनिश्चित करने का एक अभिन्न अंग है।

निम्नलिखित (तुच्छ) छद्म उदाहरण पर विचार करें:

public class Example {
  public static void main (String args[]) {
    new Example();
  }

  // Application-level test.
  public Example() {
    Consumer c = new Consumer();
    System.out.println("VALUE = " + c.getVal());
  }

  // Your Module.
  class Consumer {
    private Capitalizer c;
  
    public Consumer() {
      c = new Capitalizer();
    }

    public String getVal() {
      return c.getVal();
    }
  }

  // Another team's module.
  class Capitalizer {
    private DataReader dr;
  
    public Capitalizer() {
      dr = new DataReader();
    }

    public String getVal() {
      return dr.readVal().toUpperCase();
    }
  }

  // Another team's module.
  class DataReader {
    public String readVal() {
      // Refers to a file somewhere in your application deployment, or
      // perhaps retrieved over a deployment-specific network.
      File f; 
      String s = "data";
      // ... Read data from f into s ...
      return s;
    }
  }
}

तो यह उदाहरण तुच्छ है; DataReader एक फ़ाइल से डेटा प्राप्त करता है, इसे Capitalizer पास करता है, जो सभी वर्णों को ऊपरी-मामले में परिवर्तित करता है, जो फिर Consumer को पास हो जाता है। लेकिन DataReader हमारे एप्लिकेशन वातावरण से बहुत अधिक जुड़ा हुआ है, इसलिए हम इस श्रृंखला के परीक्षण को तब तक के लिए स्थगित कर देते हैं जब तक कि हम परीक्षण रिलीज़ को तैयार करने के लिए तैयार नहीं हो जाते।

अब, मान लें, किसी अज्ञात तरीके से, कारणों से, अज्ञात कारणों से, Capitalizer में getVal() विधि toUpperCase() स्ट्रिंग से toLowerCase() स्ट्रिंग में लौटने से बदल गई:

  // Another team's module.
  class Capitalizer {
    ...

    public String getVal() {
      return dr.readVal().toLowerCase();
    }
  }

स्पष्ट रूप से, यह अपेक्षित व्यवहार को तोड़ता है। लेकिन, DataReader निष्पादन से जुड़ी कठिन प्रक्रियाओं के कारण, हम अपनी अगली परीक्षण तैनाती तक इस पर ध्यान नहीं देंगे। तो दिन / सप्ताह / महीने हमारे सिस्टम में बैठे इस बग के साथ चलते हैं, और फिर उत्पाद प्रबंधक इसे देखता है, और तुरंत आपको, टीम लीडर Consumer जुड़ जाता है। "ऐसा क्यों हो रहा है? तुम लोग क्या बदल गए?" जाहिर है, आप क्लूलेस हैं। आपको पता नहीं है कि क्या चल रहा है। आपने ऐसा कोई कोड नहीं बदला, जो इसे छू रहा हो; यह अचानक क्यों टूट गया है?

आखिरकार, टीमों और सहयोग के बीच चर्चा के बाद, इस मुद्दे का पता लगाया जाता है, और समस्या हल हो जाती है। लेकिन, यह प्रश्न पूछती है; इसे कैसे रोका जा सकता था?

दो स्पष्ट बातें हैं:

टेस्ट को स्वचालित करने की आवश्यकता है

मैनुअल टेस्टिंग पर हमारी निर्भरता इस बग को बहुत दूर तक किसी ओर का ध्यान नहीं जाने देती। हमें उस प्रक्रिया को स्वचालित करने का एक तरीका चाहिए जिसके तहत बग को तुरंत पेश किया जाता है । अब से 5 सप्ताह नहीं। अब से 5 दिन नहीं। अब से 5 मिनट नहीं। अभी।

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

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

टेस्ट को ठीक-ठाक करने की जरूरत है

हमारे ऊपर के उदाहरण में नोट की गई दूसरी समस्या बग को ट्रेस करने में लगने वाले समय की मात्रा है। उत्पाद प्रबंधक ने आपको पिंग किया जब परीक्षकों ने इसे देखा, तो आपने जांच की और पाया कि Capitalizer काफी खराब डेटा लौट रहा था, आपने अपने निष्कर्षों के साथ Capitalizer टीम को पिंग किया, उन्होंने जांच की, आदि आदि।

इस तुच्छ उदाहरण की मात्रा और कठिनाई के बारे में मैंने यही बात कही है। स्पष्ट रूप से किसी को भी जावा के साथ अच्छी तरह से वाकिफ होने से शुरू की गई समस्या का जल्द पता चल सकता है। लेकिन यह अक्सर बहुत अधिक है, मुद्दों का पता लगाने और संवाद करने के लिए बहुत अधिक कठिन है। हो सकता है कि Capitalizer टीम ने आपको कोई स्रोत प्रदान करने वाला JAR प्रदान किया हो। शायद वे दुनिया के दूसरी तरफ स्थित हैं, और संचार घंटे बहुत सीमित हैं (शायद ई-मेल जो दैनिक रूप से भेजे जाते हैं)। इसके परिणामस्वरूप सप्ताह या उससे अधिक समय लगने वाले कीड़े हो सकते हैं (और, फिर से, दिए गए रिलीज़ के लिए इनमें से कई हो सकते हैं)।

आदेश में इस के खिलाफ कम करने के लिए में, हम के रूप में ठीक पर कठोर परीक्षण संभव के रूप में एक स्तर चाहते हैं (आप भी मोटे कणों का मॉड्यूल परस्पर प्रभाव ठीक से सुनिश्चित करने के लिए परीक्षण कर रहा हूँ, लेकिन है कि हमारे केन्द्र बिन्दु यहाँ नहीं है)। हम कठोरता से निर्दिष्ट करना चाहते हैं कि सभी आउटवर्ड-फेसिंग कार्यक्षमता (न्यूनतम पर) कैसे संचालित होती है, और उस कार्यक्षमता के लिए परीक्षण।

इकाई-परीक्षण दर्ज करें

कल्पना कीजिए कि हमारे पास एक परीक्षण था, विशेष रूप से यह सुनिश्चित करना कि Capitalizer का getVal() विधि किसी दिए गए इनपुट स्ट्रिंग के लिए एक पूंजीकृत स्ट्रिंग लौटाए। इसके अलावा, कल्पना कीजिए कि परीक्षण चलाया गया था इससे पहले कि हम कोई कोड भी लगाए। बग को सिस्टम में पेश किया गया (अर्थात, toUpperCase() को toLowerCase() ) से toLowerCase() कारण कोई समस्या नहीं होगी क्योंकि बग को सिस्टम में कभी पेश नहीं किया जाएगा । हम इसे एक परीक्षण में पकड़ लेंगे, डेवलपर (उम्मीद) को अपनी गलती का एहसास होगा, और एक वैकल्पिक समाधान उनके इच्छित प्रभाव को पेश करने के तरीके तक पहुंच जाएगा।

इन परीक्षणों को लागू करने के तरीके के रूप में यहां कुछ चूक हैं, लेकिन वे फ्रेमवर्क-विशिष्ट प्रलेखन (टिप्पणियों में जुड़े) में शामिल हैं। उम्मीद है, यह एक उदाहरण के रूप में कार्य करता है कि यूनिट परीक्षण महत्वपूर्ण क्यों है।