कई जावास्क्रिप्ट चौखटे एक विचार की पेशकश करते हैं कि कोड को कैसे देखना चाहिए। इसके अलावा, यह केवल शैली के बारे में नहीं है, यह स्क्रिप्ट लिखने के बारे में है। यह जावास्क्रिप्ट के लगभग पूर्ण लोकतांत्रिक स्वरूप के कारण है, हां, यह वही है कि बहु-प्रतिमान भाषा सी-जैसे सिंटैक्स, प्रोटोटाइप विरासत, गतिशील टाइपिंग और कार्यान्वयन में ब्राउज़र से ब्राउज़र तक भिन्न है। इसलिए, जब यह परीक्षण संचालित जावास्क्रिप्ट की बात आती है, तो मैं समझता हूं कि यह केवल एक विशेष प्रोग्रामिंग शैली के बारे में नहीं है, बल्कि एक विशेष ढांचे के लिए विशेष तकनीकी सिद्धांतों के बारे में है जो जेएस अनुप्रयोगों का परीक्षण करने की अनुमति देता है।
इस लेख में मैं खुद से तर्क करूंगा कि परीक्षण योग्य जावास्क्रिप्ट कोड क्या है और अगर मैं इसका उपयोग करना शुरू कर दूंगा तो कितना खर्च होगा।
ध्यान: लंबी पोस्ट।इसके अलावा, मैं
मानूंगा कि पाठक
qUnit और / या
जैस्मीन से थोड़ा परिचित है। आप 10 मिनट में सबसे ऊपर चल सकते हैं, यह इस लेख के लिए पर्याप्त है। हमेशा की तरह, दर्शन और सामान्यीकरण में अधिक समय और ऊर्जा लगती है। वास्तव में, मेरे लिए, मैंने इस लेख में एनोटेशन में प्रस्तुत सभी सवालों के जवाब दिए, मुझे बस इसे पढ़ना
था और याद रखना था कि यूनिट टेस्ट क्या हैं। तथ्य यह है कि मुझे कभी भी फ्रंट-एंड यूनिट परीक्षणों से निपटना नहीं था, इसलिए मुझे इस तकनीक पर संदेह था। मैं नीचे मुख्य कठिनाइयों को रेखांकित करने का प्रयास करूंगा। मैं आपको ग्राहक कोड के यूनिट परीक्षण के खिलाफ या घोषणापत्र के रूप में लेख नहीं लेने के लिए भी कहता हूं।
इसके अलावा, हमें याद रखना चाहिए कि परीक्षण के लिए रूपरेखा एक दूसरे से अलग हैं। मैंने मुख्य असहमति से छुटकारा पाने की कोशिश की, लेकिन इसमें कोई संदेह नहीं है कि, उदाहरण के लिए, जैस्मिन qUnit की तुलना में परीक्षण योग्य कोड लिखने में अधिक स्वतंत्रता देता है। फिर भी, लेख में वर्णित कठिनाइयाँ वहाँ और वहाँ दोनों पैदा होती हैं।
और इसलिए चलो।
अनाम कार्य
पहला सवाल था: “ठीक है, लेकिन अनाम कार्यों का परीक्षण कैसे करें? यदि मेरा कोड ठोस अनाम कॉलबैक और अन्य लैम्ब्डा जादू है तो मुझे क्या करना चाहिए? " आधिकारिक दस्तावेज ने काफी सहजता से समझाया कि अतुल्यकालिक कॉल के साथ क्या करना है, लेकिन उनमें से एक भी गुमनाम नहीं था।
var callBack = function(x){ ... } someAsyncFunction(someOptions, callBack);
और
someAsyncFunction(someOptions, function(x){ ... });
कुछ अलग चीजें, सहमत हैं। लेकिन जावास्क्रिप्ट एप्लिकेशन ऐसे निर्माणों से भरे हुए हैं। पारंपरिक jQuery का निर्माण
$(document).ready(function(){
डोम को तैयार होने से पहले एप्लिकेशन को चलने से रोकने का लक्ष्य है। या यहां तक कि एक सामान्य फ़ंक्शन में एप्लिकेशन को सामान्य रूप से लपेटना, ताकि वैश्विक नामस्थान को अव्यवस्थित न किया जा सके:
(function(){ ... })()
यह बहुत स्पष्ट नहीं है कि इन कार्यों का परीक्षण कैसे करें यदि वे पहचानकर्ता द्वारा सुलभ नहीं हैं। अगर उनकी पूरी बात उन तक पहुँच नहीं है। यह पता चला है कि आपको उन तक पहुंच प्रदान करने की आवश्यकता है।
$(document).ready(Application) function Application () {
और अब एप्लिकेशन को qUnit में इस तरह से परीक्षण किया जा सकता है:
test('Application Constructor is loaded', function () { ok(window.Application !== undefined , ' '); });
लेकिन एक समस्या है। लेकिन क्या होगा अगर मैं वैश्विक नामस्थान को रोकना नहीं चाहता? दुर्भाग्य से, कम से कम एक नाम के लिए कांटा लगाना होगा। कम से कम
बैकडोर मैनिपुलेशन जैसी प्रथा है। जेएस में कुछ इसी तरह वैश्विक विंडो ऑब्जेक्ट के माध्यम से लागू किया जा सकता है, जिसमें आप एक संपत्ति बना सकते हैं जिसमें आवेदन के लिए एक लिंक स्टोर करना है, उदाहरण के लिए:
(function(){ function Application(){
वहां तुम जाओ। लेकिन हम एक अनावश्यक निर्माण शुरू करते हैं और यह अभी भी हमें विंडो ऑब्जेक्ट में अनावश्यक नामों से नहीं बचाता है। यह दुखद है। इस स्तर पर, मेरा आंतरिक डिबेटर एक उचित सवाल पूछता है: वास्तव में, आप पूरे आवेदन का परीक्षण क्यों कर रहे हैं,
यूनिट परीक्षण कहां हैं? मेला। मैं पूरे आवेदन का परीक्षण कर रहा हूं। लेकिन आखिरकार, ये जेएस पर सबसे अधिक बार आवेदन हैं, वे (लगभग) हमेशा एक ही होते हैं। कोई भी अनुप्रयोग तर्क को उस भाग से अलग नहीं करेगा जो डेटा को संसाधित करता है, इन मॉड्यूल को अलग-अलग तरीकों से कनेक्ट करें, अगर यह वास्तव में एक विशाल अनुप्रयोग नहीं है, जिसे इस तरह के दृष्टिकोण की आवश्यकता है। हर एप्लिकेशन को आवश्यकता जैसी चीजों की आवश्यकता नहीं होती है। जेएस
तर्क # 1: आपको एप्लिकेशन को विभिन्न मॉडल टुकड़ों में विभाजित करने और उन्हें अलग से परीक्षण करने की आवश्यकता है, क्योंकि यह इकाई परीक्षणों का अर्थ है। प्रत्येक इकाई में, आपका अपना नाम स्थान हो सकता है (पूरी इकाई को एक अलग फ़ंक्शन में लागू करके) और समस्या हल हो जाती है।
काउंटररगमेंट # 1: जावास्क्रिप्ट शास्त्रीय अर्थ में एक ओओपी भाषा नहीं है, ताकि कक्षा के तरीकों का परीक्षण करना संभव हो। OOP का कार्यान्वयन, जो JavaScipt में व्यक्तिगत वस्तुओं का परीक्षण करने की क्षमता प्रदान करता है, अत्यधिक कोड की समस्याओं से भरा है। (यह दावा करने के लिए कि मैं कठोर प्रमाण नहीं दूंगा, मैं आपको केवल यह याद दिलाता हूं कि JS में कोई सार्वजनिक और निजी कुंजी नहीं है। इसके अलावा, यह याद रखना पर्याप्त है कि कौन सी कक्षाएं हृदय के लिए मधुर हैं और कॉफीस्क्रिप्ट में उनकी विरासत को जावास्क्रिप्ट में अनुवाद किया गया है)।
लेकिन चूंकि परीक्षण-संचालित जावास्क्रिप्ट है, इसलिए एप्लिकेशन ऑब्जेक्ट मॉडल को व्यवस्थित करने के लिए ऐसी शैली है ताकि इसका परीक्षण किया जा सके ...
विरासत
सामान्य तौर पर, जावास्क्रिप्ट में OOP, प्रोटोटाइप वंशानुक्रम, आदि गर्म बहस के लिए उपजाऊ जमीन है, जो इस लेख में ऐसा नहीं है। लेकिन इससे पहले कि आप परीक्षण-संचालित संदर्भ में वंशानुक्रम की खोज शुरू करें, मैं
डगलस क्रॉकफोर्ड और निकोलस ज़कास को जावास्क्रिप्ट में विरासत के आयोजन के सकारात्मक और नकारात्मक पहलुओं के बीच रखने के लिए "जावास्क्रिप्ट अनुप्रयोगों का अनुकूलन" पढ़ने की सलाह देता हूं।
टेस्टेबल इनहेरिटेंस शायद उन हिस्सों में से एक है जिसने मुझे सुखद आश्चर्यचकित किया है कि जब मैंने जावास्क्रिप्ट में कैनोनिकल प्रोटोटाइप इनहेरिटेंस का पालन किया तो यह अनावश्यक कठिनाइयों का कारण नहीं था। वास्तव में, अगर हमारे पास किसी वस्तु तक पहुंच है, तो हम तुरंत इसके तरीकों तक पहुंच सकते हैं और तुरंत उन्हें दूर-दूर तक परीक्षण कर सकते हैं। उदाहरण के लिए, मैं किसी वस्तु के प्रोटोटाइप में किसी संख्या के निरपेक्ष मान की गणना करने के लिए एक फ़ंक्शन जोड़ता हूं:
myObject.prototype.abs = function(x){return x>0 ? x : -x;}
यह सारी सादगी एक विवरण की कीमत पर आती है, जो कई जावास्क्रिप्ट के एक महत्वपूर्ण दोष पर विचार करते हैं। ऐसा इसलिए है क्योंकि ऑब्जेक्ट में निजी और सार्वजनिक गुण नहीं हैं। वे सभी उपलब्ध हैं। इस प्रकार, हम फिर से इस निष्कर्ष पर पहुंचे कि केवल उन कार्यों और विधियों का परीक्षण करना संभव है जो एक्सेस किए गए हैं। किसी को केवल किसी वस्तु के सार्वजनिक और निजी गुणों की नकल करना शुरू करना है, उदाहरण के लिए:
function myClass (options){ var privateMethod = function(){ ... } var that = { publicMethod : function(){ ... } } return that; }
PublicMethod बंद करने के लिए पहुँच संभव है क्योंकि यह एक वस्तु है कि यह एक संपत्ति के रूप में शामिल देता है। समस्या यह है कि आपको निजी मेथोड फ़ंक्शन के लिए बाहर से प्रवेश नहीं मिल सकता है, हालांकि यह myClass फ़ंक्शन के दायरे में जगह लेता है और सभी myClass क्लोजर के अंदर एक्सेस किया जा सकता है, लेकिन आपके पास फ़ंक्शन को किसी अन्य दायरे तक पहुंच नहीं है। हम पैराग्राफ 1 पर लौटते हैं।
यह विशेष रूप से महत्वपूर्ण है जब हम उन अनुप्रयोगों को लिखते हैं जहां पारंपरिक ओओपी टेम्पलेट का उपयोग किया जाता है, जिसमें कई तरीके, आंतरिक तर्क और अन्य चीजें हैं, जहां कई उदाहरणों और उनके विरासत वाले उदाहरणों का निर्माण करने वाली कोई कारखाना विधि नहीं है। संक्षेप में ...
तर्क # 2: यदि आप पारंपरिक जावास्क्रिप्ट प्रोटोटाइप वंशानुक्रम का उपयोग करते हैं, तो एप्लिकेशन का संपूर्ण ऑब्जेक्ट मॉडल अनावश्यक प्रयास के बिना परीक्षण के लिए स्वचालित रूप से उपलब्ध है।
काउंटररगमेंट # 2: जावास्क्रिप्ट में इनहेरिटेंस (जिनमें से कई बहुत लोकप्रिय हैं) को लागू करने के लिए एक हजार और एक तरीके हैं, जो डेवलपर को वर्ग आवृत्ति विधियों तक पहुंच से वंचित करते हैं।
परीक्षण संचालित जावास्क्रिप्ट में वंशानुक्रम और ऑब्जेक्ट प्रोग्रामिंग को लागू करने की समस्या यह है कि कुछ विधियाँ समग्र रूप से उदाहरण की स्थिति को प्रभावित करती हैं। यह कैसे परीक्षण करें कि एक निश्चित घटना में, उदाहरण ने कुछ आंतरिक संपत्ति को बदल दिया है, जो अन्य कार्यों पर निर्भर नहीं करता है, उदाहरण के लिए, जब माउस होवर अपना रंग बदलता है? बशर्ते कि हम उन चौखटों पर भरोसा करें जिनके साथ हम इस मैपिंग को लागू करते हैं। लेकिन विभिन्न रूपरेखाओं की मदद से हम जो कुछ भी करते हैं वह राज्यों और केवल राज्यों को बदलता है।
दुर्भाग्य से, वास्तविकताओं के साथ बाधाओं पर एक में इकाई परीक्षण के विचार। कोई भी (लगभग कोई भी) एक मॉडल विकसित नहीं करता है, फिर जावास्क्रिप्ट लिखता है - एक स्क्रिप्ट, और फिर केवल इस व्यवसाय के लिए एक जीयूआई बनाता है, सबसे अधिक बार सब कुछ काफी विपरीत होता है, प्रोग्रामर एप्लिकेशन इंटरफ़ेस प्राप्त करता है और "इसे काम करते हैं" सुनता है। मैं यह नहीं कह रहा हूं कि पहला मामला असंभव या निरर्थक है, इसके विपरीत - यह सबसे अच्छा तरीका है, लेकिन अफसोस, सामने का अंत एक विकास मंच के रूप में माना जाता है, जो बैक-एंड
के काम को
प्रतिबिंबित करने का कार्य करता है।
सिस्टम राज्यों के विषय पर लौटते हुए, मैं मुख्य समस्या पर आता हूं। मान लें कि हम पूरी तरह से सभी jQuery पर भरोसा करते हैं और सुनिश्चित करें कि तर्क में "# 000000" के रूप में स्ट्रिंग प्राप्त करने वाले फ़ंक्शन इस रंग में आंकड़ा पेंट करेंगे और त्रुटियों के बिना इसे करेंगे। मान लीजिए कि DOM के साथ काम करने के लिए चौखटे, और अन्य डिस्प्ले में शामिल लोग, फ़ंक्शन के रूप में परीक्षण करने के लिए महत्वपूर्ण नहीं हैं, जहां डेटा को एप्लिकेशन में संसाधित किया जाता है। लेकिन एक को दूसरे से अलग कैसे करें? शुद्ध कार्यों को कैसे लिखना है कि यह दुष्प्रभावों को लिखे बिना परीक्षण करने के लिए समझ में आता है?
var a = 10; function f(x) { a = x; }
यह फ़ंक्शन साफ नहीं है, अफसोस। यह डेटा प्राप्त करता है और सिस्टम की स्थिति (चर का मान) को बदलता
a ।
शुद्ध कार्य
शुद्ध कार्य अच्छे हैं। यह अच्छा है जब फ़ंक्शन सिस्टम की स्थिति को नहीं बदलते हैं। जब फ़ंक्शन डेटा प्राप्त करते हैं, तो वे उनके साथ कुछ करते हैं और डेटा वापस करते हैं। और वे कुछ और नहीं करते।
लेकिन जावास्क्रिप्ट में दो बारीकियां हैं।
पहला : जावास्क्रिप्ट में, फ़ंक्शन ऑब्जेक्ट हैं, और सिस्टम मूल रूप से ऑब्जेक्ट हैं, अर्थात, सिस्टम के कार्य फ़ंक्शन द्वारा निर्मित होते हैं। सिस्टम के राज्य कार्यों के राज्य हैं। वस्तु और विधि की अवधारणा का कोई स्पष्ट पृथक्करण नहीं है। सब कुछ अंततः ज़ेन वस्तुओं या कार्यों में विलीन हो जाता है, यदि आप करेंगे। दूसरे शब्दों में, हम कार्यों के साथ वस्तुओं का निर्माण करते हैं, फ़ंक्शंस के साथ हम डेटा की गणना करते हैं और उन्हें उन कार्यों में पास करते हैं जो मूल वस्तुओं को बदलते हैं।
(Xzibit और हस्ताक्षर 'यो डॉग' के साथ एक तस्वीर होनी चाहिए)दूसरा : साइड-इफेक्ट्स में क्लाइंट-साइड जावास्क्रिप्ट का सार नहीं है? यही है, प्रदर्शन में, गतिशीलता में। पिछली बार जब आपने ब्राउज़र कंसोल में उपयोगकर्ता को परिणामी डेटा वापस करने के लिए कुछ क्रूर रीमैन इंटीग्रल लिया था? मुझे बहुत आश्चर्य होगा अगर किसी को क्लाइंट की तरफ से कम से कम एक बार ऐसी समस्याओं को हल करना पड़ा, और यहां तक कि प्रदर्शन के बिना भी। यदि आवेदन में कोई महत्वपूर्ण तर्क नहीं है, लेकिन केवल एक मैपिंग है, तो संक्षेप में यहां परीक्षण करने के लिए कुछ भी नहीं है।
यहाँ एक सुंदर पाठ्यपुस्तक उदाहरण है:
इनपुट दिया गया है, कीडाउन इवेंट पर नियमित अभिव्यक्ति द्वारा इनपुट की सामग्री का सत्यापन शुरू करना आवश्यक है। यदि दर्ज स्ट्रिंग वैध है, तो हम इनपुट को हरे रंग में पेंट करते हैं, अन्यथा लाल रंग में।
$("#myPrettyInput").on("keydown", function(){ if(___){ ... }else{ ... } });
साइड इफेक्ट्स (सीएसएस परिवर्तन) से डेटा प्रोसेसिंग (सत्यापन) को अलग करने के लिए, आप निम्नलिखित कुन्ष्टुक कर सकते हैं:
$("#myPrettyInput").on("keydown", function(){ var val = $(this).val(); var regex = ... - ; if(validate(val, regex){
एक तरफ, क्या गलत है? लगता है कि आपने एक अतिरिक्त कार्य लिखा है? दरअसल, पहले मामले में, अगर
$(this).val().match(regex).length तरह कुछ बदसूरत अभिव्यक्ति होती, तो सबसे अधिक संभावना है, और अब हमारे पास खुद के लिए एक सुंदर स्वच्छ कार्य है। और इससे कोई फर्क नहीं पड़ता कि फ़ंक्शन की एक ही अभिव्यक्ति है, मुख्य बात यह है कि आप इसका परीक्षण कर सकते हैं! वास्तव में, इस तरह के एक सरलीकृत उदाहरण के साथ, सब कुछ काफी उचित और सभ्य दिखता है। ऐसा लगता है कि हमने केवल एक फ़ंक्शन को उजागर करके परीक्षण क्षमता हासिल की है, लेकिन ...
तर्क # 3: हमें परीक्षण योग्य कोड प्राप्त हुआ और किसी भी समय हम यह जांच सकते हैं कि हमारी मान्यता काम करती है या नहीं। इसके अलावा, हमने इवेंट हैंडलर में विशाल भावों से छुटकारा पाया।
प्रतिवाद # 3: हमने एक और चर पेश किया। लेकिन क्या होगा यदि सत्यापन इतना सरल नहीं है, लेकिन इसमें अजाक्स कॉल शामिल है? उदाहरण के लिए, यदि उपयोगकर्ता नाम व्यस्त है तो जाँच। और सख्त डेटा प्रोसेसिंग से साइड इफेक्ट्स के पृथक्करण का एहसास करने के लिए, आपको किसी इवेंट हैंडलर से किसी फ़ंक्शन को हटाने से अधिक कुछ चाहिए।
counterexample:
var validate = function(str, regex){ if(_____regexp){ $.ajax({ ... succsess : function(data){
दुर्भाग्य से, कॉलबैक पहचान पर्याप्त नहीं है।
var validate = function(str, regex){ function ajax_validate(data){
बेशक, पिछली सूची में, ajax_validate फ़ंक्शन शुद्ध है (यह सत्यापन का परिणाम देता है, जो हमेशा या तो सही या गलत होता है), लेकिन फिर भी आप इसे किसी भी तरह से परीक्षण नहीं कर सकते, क्योंकि यह मान्य के अंदर एक चर है। इसे एक वैध बंद करें? एक बेवकूफ समाधान - इस मान्य से एक वर्ग में बदल जाता है, यह साफ होना बंद हो जाता है। क्या तब सभी कड़े जाँचों को चालू कर सकते हैं जो कुछ अलग मॉड्यूल के बंद होने पर सही या गलत हो सकते हैं, जो कि आवेदन में सभी प्रकार के सत्यापन द्वारा विशेष रूप से कब्जा कर लिया जाएगा? परीक्षणशीलता के दृष्टिकोण से, यह पूरी तरह से संतोषजनक समाधान है, प्रतिरूपकता के दृष्टिकोण से भी। लेकिन मुझे आशा है कि आपने अनुसरण किया था कि कैसे काम की मात्रा में वृद्धि हुई है। और मैं अनिवार्य रूप से आवेदन में कुछ विशेष नहीं जोड़ रहा था। मैं खुद से पूछता हूं, बीच का मैदान कहां है?
इस सवाल का जवाब देना तर्कसंगत लगता है कि हमें डेटा हीलर को एक हीप में, इवेंट हैंडलर को दूसरे में रखना होगा। इसलिए मैं उस भाग का परीक्षण करने से इनकार करता हूं जो वांछित रंग में इनपुट को पेंट करता है, लेकिन कार्यक्रम के उस हिस्से का परीक्षण करना संभव बनाता है जहां यह
गणना की
जाती है कि इनपुट को किस रंग से रंगना है । लेकिन फिर से, चेतावनी के साथ कि यदि आवेदन बहुत बड़ा / जटिल / भ्रमित नहीं है। यदि यह सच है, तो अतिरिक्त मॉड्यूल शुरू करना, समय बिताना बेहतर है, लेकिन परीक्षण क्षमता और आगे के उपयोग में आसानी। और यदि एप्लिकेशन को विशेष ट्रिक्स की आवश्यकता नहीं है, तो मैं यह करूंगा:
$("#myPrettyInput").on("keydown", function(){ var val = $(this).val(); if(validate(val,regex)){ var ajaxValidationResult = false; $.ajax({ ... success : function(data){ if(ajax_validate(data)){ ajaxValidationResult = true;
मेरे लिए, यह परीक्षण क्षमता के लाभों के लिए अतिरिक्त काम का एक बिल्कुल स्वीकार्य दृष्टिकोण है। लेकिन, मैं इसे बीच का रास्ता नहीं कह सकता। मेरे फैसले क्या हैं? वास्तव में कोई सार्वभौमिक नहीं। आपकी इच्छानुसार इसे परीक्षण योग्य बनाने के लिए जावास्क्रिप्ट में निर्मित कई विशेषताएं हैं। यह वह जगह है जहाँ जावास्क्रिप्ट की कार्यात्मक प्रकृति पॉप अप होती है। जहां आप फंक्शन को फंक्शन पास कर सकते हैं और फंक्शन भी वापस कर सकते हैं। यह इस अर्थ में सुविधाजनक है कि एप्लिकेशन लॉजिक को काफी ढीली घोषणात्मक शैली में निष्पादित किया जा सकता है (यह वह भाग है जो इकाई परीक्षणों से संबंधित नहीं है), जबकि प्रोग्राम के उन हिस्सों को जो डेटा प्रोसेसिंग के लिए जिम्मेदार हैं, उन्हें परीक्षण योग्य के रूप में छोड़ा जाना चाहिए। मैं अक्सर निम्नलिखित योजना का उपयोग करता हूं:
function App(){ function Vehicle(){
इस तरह आप किसी भी क्लास के क्लोजर तक पहुँच सकते हैं। अंत में, मैं पिछले दरवाजे के माध्यम से या केवल वांछित वस्तु को वापस करने के लिए पहुंच प्राप्त करने का तरीका चुन सकता हूं। हालाँकि, सार्वजनिक / निजी तरीकों की ऐसी नकल पूरी तरह से सार्वजनिक / निजी तरीकों के विचार को पूरा नहीं करती है, लेकिन यह केवल अन्य scopes से उपलब्ध कार्यों के बीच परिसीमन के रूप में कार्य करती है या नहीं, जो कि परीक्षण क्षमता प्रदान करने के लिए बल्कि बदसूरत ऐड-ऑन है, और सार्वजनिक को अलग करने के लिए नहीं। और शास्त्रीय OOP के निजी तरीके। अधिक हद तक, इस तरह से यह साइड इफेक्ट्स के साथ शुद्ध कार्यों और कार्यों को अलग करने के लिए समझ में आता है। इसके अलावा, किसी को यह याद रखना चाहिए कि एप्लिकेशन संरचना का ऐसा संगठन सबसे अधिक उत्पादक है और अनुप्रयोगों के लिए कई मॉड्यूल के साथ बड़े, कई गुना बड़े अनुप्रयोगों के लिए अधिक उपयुक्त है जो कक्षाओं के कई उदाहरणों का उपयोग करते हैं।
डेटा प्रोसेसिंग और डिस्प्ले के पृथक्करण पर लौटते हुए, मैं कहूंगा कि कुछ लाइब्रेरीज़ साइड इफेक्ट्स (मुख्य रूप से कार्यात्मक और / या घोषणात्मक) से शुद्ध कार्यों को अलग करने पर मजबूर करती हैं। अन्य, दुर्भाग्य से, विशेष रूप से इस विचार का समर्थन नहीं करते हैं। हालांकि उस समय के लिए, जब मैं जावास्क्रिप्ट से परिचित हूं, मैं आश्वस्त हूं कि कुछ भी असंभव नहीं है। सवाल बिल्कुल अलग है। किस प्रयास की कीमत पर?
उदाहरण के लिए,
इस लेख में , मैं काफी सरल अनुप्रयोग (खिलौना) का परीक्षण कर रहा हूं, और क्योंकि मैं bacon.js का उपयोग करता हूं - एक घोषणात्मक पुस्तकालय, जिसका सार डेवलपर को नेस्टेड कॉलबैक के नरक से बचाने के लिए होता है, जो घटना श्रोताओं पर लटका हुआ है, मैं अनावश्यक नुकसान के बिना आवेदन लाने में सक्षम था। परीक्षण योग्य रूप में।
सारांश:दुर्भाग्य से, मैं इसके बजाय "हर उपकरण अपनी जगह में उपयुक्त है" की तुलना में अधिक समझदार कुछ भी नहीं कह सकता। मैं केवल qUnit और जैस्मीन का उपयोग कम या ज्यादा बड़े अनुप्रयोगों के लिए क्लाइंट कोड के परीक्षण में करता था। लेकिन ये ऐसे मामले थे, जब कोड की एक भी पंक्ति लिखे बिना, मेरे पास पहले से ही एक कूबड़ था कि इस आवेदन में मैं वास्तव में डेटा प्रोसेसिंग से साइड इफेक्ट्स को कैसे अलग कर सकता हूं, और अगर मैं परीक्षण योग्य कोड लिखता हूं, तो आवेदन एक अस्पष्ट सेटिंग में नहीं बदल जाएगा।
अंत में, मैं कहना चाहूंगा कि इकाई परीक्षण का विचार NodeJS के मॉड्यूलर सार के साथ अच्छा समझौता है। इस लेख में NodeJS प्लेटफ़ॉर्म पर शोविंग टेस्ट संचालित प्रोग्रामिंग शानदार होगी, हालांकि विषय निश्चित रूप से रोमांचक है। इसलिए, अगर किसी को दिलचस्पी है, तो मैं इस बारे में अगले लेख में लिखूंगा।