2011-03-30 16 views
6

मैं सहायक कार्यों बनाया है एक jQuery प्लगइन में, इसjquery प्लगइन में आंतरिक कार्यों का परीक्षण कैसे करें?

(function($) { 

    var someHelperFunction = function(s, d) { 
    return s*d; 
    } 
    var someOtherHelperFunction = function(s) { 
    return s*2; 
    } 

// here goes the normal plugin code 

})(jQuery); 

अब मैं इकाई परीक्षण यह करने के लिए सक्षम होने के लिए, बाहर से someHelperFunction कॉल करना चाहते हैं की तरह, कि संभव है किसी भी तरह?

+0

चूंकि आप बाहर से विधियों तक नहीं पहुंच सकते हैं, यह संभव नहीं है। –

उत्तर

0

सहायकों प्लगइन, एक गुमनाम समारोह है जो अंदर scoped रहे हैं एक जावास्क्रिप्ट इकाई परीक्षण लेते हैं, और आप चर इसके अंदर घोषित उपयोग नहीं कर सकते।
यदि आप इसका परीक्षण करना चाहते हैं, तो कार्यों के सामने var कीवर्ड ड्रॉप करें। इससे कार्यों को ग्लोबल के रूप में घोषित किया जाएगा (उन्हें विंडो ऑब्जेक्ट से जोड़ दिया जाएगा), जिससे उन्हें विंडो स्कोप से दिखाई देने की क्षमता मिल जाएगी (someHelperFunction या window.someHelperFunction पर कॉल करके)। इसलिए
, परीक्षण के लिए:

(function($) { 
    someHelperFunction = function(s, d) { 
     return s*d; 
    } 
    someOtherHelperFunction = function(s) { 
     return s*2; 
    } 
    // here goes the normal plugin code 
})(jQuery); 

के बाद परीक्षण खत्म हो गया है, var कीवर्ड फिर से जोड़ें।

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

(function($, global) { 
    someHelperFunction = function(s, d) { 
     return s*d; 
    } 
    someOtherHelperFunction = function(s) { 
     return s*2; 
    } 

    var api = { 
     someHelperFunction: someHelperFunction, 
     someOtherHelperFunction: someOtherHelperFunction 
    }; 

    // decide whether you want to expose your api or not 
    if(makeGlobal) { 
     global.api = api; 
    } 
})(jQuery, this); 
+4

टाइप करने से पहले अच्छी तरह से पढ़ें इस के साथ मजा लें। –

+3

अपने निजी कार्यों का परीक्षण करने के लिए वैश्विक चर का उपयोग न करें। यह एक अच्छा जवाब नहीं है क्योंकि यह बुरे प्रथाओं का समर्थन करता है। – drublic

2

प्रति this related question, मैं बस बाहरी इंटरफ़ेस का परीक्षण करता हूं।

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

-3

qunit पर एक नज़र, lib

+1

यह सामान्य रूप से परीक्षण के बारे में नहीं है। यह स्थानीय तरीकों का परीक्षण करने के बारे में है। –

+0

ओह, क्षमा करें .. बहुत जल्दी बात की। स्वयं को ध्यान दें: – cander

1

आंतरिक कार्यों का परीक्षण है कि एक अच्छा संकेत है कि वे शायद कहीं न कहीं एक अलग मॉड्यूल में हो सकता है और के रूप में इंजेक्ट किया जाना चाहिए की जरूरत है निर्भरता और आपके ऑब्जेक्ट्स सार्वजनिक इंटरफ़ेस कार्यान्वयन के भीतर उपयोग किया जाता है। ऐसा करने के लिए यह "टेस्टेबल" तरीका है।

var myActualImplementationTestTheHellOutOfMe = function(s, d) { 

    return s*d; 

} 

(function($, helper) { 

    var someHelperFunction = function(s, d) { 
    return helper(s, d); 
    } 
    var someOtherHelperFunction = function(s) { 
    return s*2; 
    } 

// here goes the normal plugin code 

})(jQuery, myActualImplementationTestTheHellOutOfMe); 
1

आप जावास्क्रिप्ट के सिद्धांतों पर भी विचार करना चाहेंगे। दो कार्यान्वयन हैं जिनमें से मुझे पता है: इयान बिकिंग doctest.js, और मेरा खुद का doctest

+0

मैं प्रत्येक पुस्तकालय के पेशेवरों और विपक्ष में वजन कम करने की कोशिश कर रहा हूं लेकिन वे बहुत समान दिखते हैं। सबसे अच्छा लेखक के रूप में - क्या आप एक छोटी सी दौड़ दे सकते हैं? मेरा उपयोग-मामला यूनिट परीक्षणों को [व्हाइट-स्पेस] में जोड़ना है (https://github.com/dotnetCarpenter/white-space/issues/6) जिसमें सार्वजनिक एपीआई नहीं है और HTML फिक्स्चर और दस्तावेज़ का परीक्षण करने की आवश्यकता है .readyState। – dotnetCarpenter

+0

सबसे पहले, सिद्धांत उपयोग उदाहरणों का परीक्षण करने की अनुमति देते हैं, यह सुनिश्चित करते हुए कि वे अद्यतित रहें। डॉक्टर वास्तव में * दस्तावेज * परीक्षण के लिए हैं, कोड नहीं। दूसरा, सिद्धांत [शुद्ध कार्यों] के लिए अच्छी तरह से काम करते हैं (http: // en।wikipedia.org/wiki/Pure_function), लेकिन कॉलबैक-आधारित कोड के लिए नहीं। मैं एक समर्पित परीक्षण ढांचे का उपयोग करने का सुझाव देते हैं। – davidchambers

+0

मुझे वास्तव में सबसे अच्छा क्या पसंद है, यह है कि मुझे केवल परीक्षण के लिए कृत्रिम रूप से सार्वजनिक एपीआई बनाना नहीं है। जहां तक ​​मैं समझता हूं, मैं बंद करने के अंदर विधि/फ़ंक्शन दस्तावेज़ लिख सकता हूं और अभी भी यूनिट परीक्षणों तक पहुंच की इजाजत देता हूं। मुझे लगता है कि यह शुद्ध कार्यों की सीमा है जो मेरे लिए एक सौदा ब्रेकर है, क्योंकि मैं वास्तव में परीक्षण कर रहा हूं, ब्राउज़र है व्यवहार। – dotnetCarpenter

संबंधित मुद्दे