टेस्ट आधुनिक software development में एक अनिवार्य तत्व हैं, लेकिन test case भी आखिरकार डेवलपर द्वारा लिखा गया code ही होते हैं, इसलिए कभी-कभी उनमें भी समस्याएँ उत्पन्न हो सकती हैं। यह लेख object-oriented दृष्टिकोण से ‘उपयोगी’ test case पर विचार करता है। (कोरियाई)

मुख्य बात यह है कि टेस्ट [encapsulated दूसरे module का परीक्षण करने की ज़िम्मेदारी रखने वाला module] हैं। इसका मतलब है कि टेस्ट भी स्पष्ट रूप से विकसित किए जाने वाले code का हिस्सा हैं, इसलिए (object-oriented paradigm में) उन्हें भी object-oriented सिद्धांतों का पालन करते हुए लगातार सुधारा और refactoring किया जाना चाहिए। तब SOLID सिद्धांतों से यह भी निकाला जा सकता है कि test case को परीक्षण किए जाने वाले module के ठोस आंतरिक तत्वों (private method आदि) तक पहुँच नहीं बनानी चाहिए और न ही उन पर निर्भर होना चाहिए। test case को आखिरकार उस module की abstract ज़िम्मेदारी की ही जाँच करनी चाहिए, इसलिए परीक्षण केवल उस module के external interface के माध्यम से ही होना चाहिए, जो इस ज़िम्मेदारी को प्रतिबिंबित करता है.

व्यक्तिगत रूप से मुझे लगता है कि यह उन कई पहाड़ों में से एक है जिन्हें programming के शुरुआती सीखने वालों को पार करना पड़ता है। जब मैंने पहली बार object-oriented programming सीखी थी, तब lecture में “private method को सीधे test नहीं करना चाहिए” और उसके कारण के बारे में सुना था, लेकिन सच कहूँ तो उस समय मैं इसे ठीक से समझ नहीं पाया था। ऊपर की बातों को मैं कुछ हद तक उससे काफ़ी समय बाद समझ सका।

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.