हाय हाबरा!
मैं आपको परीक्षणों के लिए एक और फैशनेबल ढांचा प्रदान नहीं करूंगा, लेकिन परीक्षण और प्रलेखन के लिए दृष्टिकोण दिखाऊंगा, जिसका उपयोग मैं आई-फ्री में विकसित परियोजनाओं में करता हूं। आप इसे पसंद कर सकते हैं, और आप उसी तरह से परियोजनाओं का आयोजन शुरू करेंगे या मुझे स्पष्ट समस्याओं की ओर इशारा करेंगे।
कई वेब डेवलपर्स परीक्षण लिखना पसंद नहीं करते हैं, और मैं कोई अपवाद नहीं हूं। लेकिन परीक्षण कीड़े की संख्या को कम करते हैं और यदि आपका आवेदन अधिक से अधिक हो जाता है, तो आप परीक्षणों से दूर नहीं हो सकते। इसके अलावा, छोटी कंपनियों में, मैं अक्सर ऐसे जूनियर्स से मिलता हूं जो आम तौर पर टेक्स्ट एडिटर में कोड लिखना पसंद करते हैं (इससे त्रुटियों की संख्या बढ़ जाती है, क्योंकि एडिटर कोड की जांच नहीं करते हैं)। दर्द और पीड़ा के बिना धीरे-धीरे परीक्षणों का उपयोग कैसे शुरू करें! एक रास्ता है - ऑटोटेस्ट्स को जोड़ने के लिए।
बाईं ओर के चित्र में पद का सार। यह वह है जिसे मैं अपने दैनिक कार्य में याद करता था। मैं एक उपकरण चाहता था जिसे आप आसानी से कोड में पोक कर सकते हैं और इसकी उत्तरजीविता और उपयुक्तता के बारे में एक सामान्य निष्कर्ष निकाल सकते हैं।
ऑटो परीक्षण
समस्याएं हैं:- डेवलपर स्वयं परीक्षण लिखने के लिए बहुत आलसी है
- डेवलपर परीक्षण के लिए अतिरिक्त कोड लिखने के लिए बहुत आलसी है
- डेवलपर आमतौर पर परीक्षणों के बारे में सोचने के लिए बहुत आलसी होता है
समाधान: डेवलपर द्वारा उपयोग किए गए कुछ ढांचे के एपीआई के माध्यम से आवेदन से कनेक्ट करें, और इसके माध्यम से ऑटो-परीक्षण चलाएं।
कहां से कनेक्ट करें:- ईवेंट हुकिंग फ़ंक्शंस (जैसे $ ("# बटन) .click (), core.addEvent (), हेल्पर.ऑनक्लिक (), आदि)
- श्रोता कार्य (जैसे $ ("# बटन) .on (), event.listen (), mediator.listen (), आदि)
- प्रारंभिक कार्य (जैसे $) (शरीर)। पहले से ही (), utils.ready (), आदि)
- AJAX अनुरोधों के लिए कॉलबैक कार्य
क्या जाँच करें:- अमान्य तर्कों के साथ प्रदर्शन
- टाइपोस के कारण यादृच्छिक कीड़े की उपस्थिति (जैसे लापता;)
- स्क्रिप्ट के लिए आवश्यक सभी DOM तत्वों की उपस्थिति
आप यादृच्छिक मापदंडों के एक गुच्छा के साथ कोशिश / पकड़ में एक पंक्ति में सभी कार्यों को कॉल कर सकते हैं और उनके बिना। देखो कि कौन से कार्य गिरते हैं। इसके अलावा, DOM तत्वों के सभी लिंक और क्वेरी पर जाएं और लेआउट में उनकी उपस्थिति की जांच करें।
यह हमें क्या देता है:यह स्पष्ट है कि वेब एप्लिकेशन के तर्क के संदर्भ में यह काफी व्यर्थ परीक्षण है। लेकिन दूसरी ओर, बहुत अधिक प्रयास और जल्दबाजी के बिना, हम पूरी तरह से मूर्ख टाइपो और असामान्यता से विधानसभा की दोबारा जांच कर सकते हैं।
बोनस:- यह तर्क दिया जा सकता है कि इस तरह के आत्म-परीक्षण 90% एप्लिकेशन सुविधाओं को कवर कर सकते हैं
- इस तरह के परीक्षण को समर्थन, अपडेट आदि के मामले में डेवलपर से बिल्कुल किसी भी प्रयास की आवश्यकता नहीं होती है। मोटे तौर पर, वह उनके बारे में बिल्कुल नहीं सोच सकता है
- अभी भी कीड़े होंगे, इसलिए कोई अनावश्यक जांच नहीं है
- परीक्षण करने के लिए, हमें अपने आवेदन की संरचना को बदलने की आवश्यकता नहीं है
मैं फिर से दोहराता हूं:- यह इकाई परीक्षण रद्द नहीं करता है!
- यह एप्लिकेशन लॉजिक के मामले में व्यर्थ है!
- टेस्ट के लिए टेस्ट - खराब
लेकिन! यह स्वतंत्र और सरल है, और यह कुछ भी नहीं से बेहतर है। यदि आप अपने कनिष्ठों को यह दिखाते हैं, तो उन्हें विश्वास हो जाएगा कि यह वास्तव में सरल और दर्द रहित है, जिसका अर्थ है कि वे परीक्षणों के प्रति अधिक वफादार होंगे, जिसका अर्थ है कि वे जल्दी से इकाई परीक्षण लिखने के बारे में सोचेंगे।
काम की योजना:
हम अपने आवेदन मॉड्यूल का एक गुच्छा से मिलकर किया है। इसके संचालन की जांच करने के लिए, हमें प्रत्येक मॉड्यूल के लिए एक इकाई परीक्षण लिखना होगा। यह अच्छा है अगर हम ऐसा करते हैं, लेकिन, वास्तव में, अधिकांश डेवलपर्स इस पर समय नहीं बिताएंगे, खासकर छोटे अनुप्रयोगों में। इसके अलावा, यदि आप परीक्षण के लिए कुछ तैयार किए गए समाधान लेते हैं जिन्हें मॉड्यूल के कोड को बदलने की आवश्यकता होती है, तो कोई भी ऐसा नहीं करेगा। दूसरी ओर, पुस्तकालयों और अनुप्रयोग के बीच की परत में कुछ कार्यों को सम्मिलित करना बहुत आसान है (यदि आपके पास ऐसी परत नहीं है, तो आप इन कार्यों को पुस्तकालय में ही सम्मिलित कर सकते हैं)। और आउटपुट में हम पहले से ही कम से कम किसी प्रकार का परीक्षण प्राप्त कर सकते हैं (आप इसे "मूर्ख से परीक्षण" कह सकते हैं, जो एक पंक्ति में सभी बटन दबा देगा)। खैर, अगर आप अभी भी एक परत थी - आम तौर पर अद्भुत। और आप AJAX अनुरोध फ़ंक्शन का एक प्रतिस्थापन भी बना सकते हैं।
यदि आपका कोड मॉड्यूल में विभाजित है और इसे इस प्रकार बनाया गया है:
(function(global) { var module = { _methodA: function() {}, _methodB: function() {}, _methodC: function() {}, init: function() {} } module.init(); })(this);
या इसी तरह के निर्माण - फिर पूरे मॉड्यूल को एक ही बार में निर्यात किया जा सकता है।
मुझे अपने आप में एक परीक्षण वस्तु मिली और यह सब संभव है - इसे दूर करना शुरू किया:
test.add();
और फिर सब कुछ सरल है। इस परीक्षण के अंदर कई ऐरे हैं जिनमें कॉलबैक और मॉड्यूल का एक गुच्छा एकत्र किया जाता है। आउटपुट दूसरी विधि है:
test.start();
इस बिंदु पर, सरणियों में एकत्र की गई हर चीज का सत्यापन शुरू होता है। और यह सभी कोशिश / पकड़ने के निर्माण में सत्यापित है। यदि किसी की मृत्यु हो जाती है, तो एक सूचना कंसोल में पॉप अप हो जाती है और अगला शिकार सरणी से लिया जाता है।
यदि हम फ़ंक्शन का परीक्षण करते हैं, तो, एक साधारण कॉल के अलावा, उन्हें मापदंडों के साथ भी बुलाया जाता है। वास्तव में, शून्य से 4 मापदंडों तक एक विस्तृत खोज है। प्रत्येक पैरामीटर क्रम में मूल्यों की एक श्रृंखला लेता है (-1, 0, 1, "स्ट्रिंग", सच, गलत, [], {}, आदि)
यदि हम मॉड्यूल लेते हैं, तो यह एक वस्तु है। हम ऑब्जेक्ट के गुणों के माध्यम से चलते हैं, और यदि हम एक फ़ंक्शन में आते हैं - हम इसे ऊपर दिए गए एल्गोरिदम के अनुसार जांचते हैं। क्योंकि मेरे सभी मॉड्यूल में समान संरचना है, आप कुछ और बिंदुओं की जांच कर सकते हैं। उदाहरण के लिए, यह पता लगाने के लिए कि सभी DOM तत्व पाए गए / बनाए गए। उनके लिए लिंक _nodes संपत्ति में संग्रहीत हैं, जो लगभग सभी मॉड्यूल हैं। उदाहरण के लिए:
var module = { _nodes: { table: DOM_element, link: DOM_element }, _methodA: function() {}, _methodB: function() {}, _methodC: function() {}, init: function() {} }
यदि, जब हम मॉड्यूल के माध्यम से जाते हैं। \ n वस्तुएं, हम अचानक शून्य पाते हैं - इसका मतलब है कि कुछ मॉड्यूल को रोका गया है। शायद आरंभीकरण ने काम नहीं किया, या पृष्ठ के DOM संरचना में कुछ तत्व गायब हो गए। मैं तुरंत एक आरक्षण कर दूंगा कि मैं किसी तत्व का लिंक केवल एक बार खींचूं। बाकी समय यह मॉड्यूल के अंदर संग्रहीत किया जाता है और इसके बजाय:
$("#name").html("");
मेरे पास होगा:
var node = this._nodes.name; if(node) node.innerHTML = "";
स्टबी और मोकी
सर्गेई टेप्लाकोव को उद्धृत करने के लिए:
ईमानदारी से, मैं कोड के "परीक्षणनीयता" के लिए केवल डिजाइन परिवर्तनों का एक बड़ा प्रशंसक नहीं हूं। जैसा कि अभ्यास से पता चलता है, एक सामान्य OO डिजाइन या तो पहले से ही पर्याप्त रूप से "परीक्षण" है या इसे बनाने के लिए केवल न्यूनतम शरीर आंदोलनों की आवश्यकता है। इस विषय पर कुछ अतिरिक्त विचार "आदर्श वास्तुकला" लेख में पाए जा सकते हैं।
मूल यहाँ देखा जा सकता है
http://habrahabr.ru/post/134836/यदि आपने कभी उनके बारे में नहीं सुना है, तो एक स्टब सर्वर की तरह है, या किसी प्रकार की बाहरी नकली वस्तु है जो इसे एक्सेस करते समय अलग-अलग परिणाम उत्पन्न करती है। तो कहने के लिए, परीक्षण के लिए एक ठूंठ वस्तु। मोकी एक ही बात है, वे केवल उन आंकड़ों पर विचार करते हैं जो उन्होंने खींचा था और कितनी बार।
परीक्षण के लिए सर्वर पर कुछ बदलने की आवश्यकता है?- नहीं, हम सिर्फ AJAX अनुरोध के स्थान पर एक स्टब डालते हैं।
अनुप्रयोग कोड में AJAX अनुरोध के स्थान पर कुछ बदलने की आवश्यकता है?- नहीं, हम अपने कोड को छुए बिना लाइब्रेरी में क्वेरी फ़ंक्शन को बदल सकते हैं। इसलिए, यह कोई फर्क नहीं पड़ता कि फ़ंक्शन को कितनी बार और कितनी बार कहा जाएगा - यह हमेशा स्टब को खींचेगा।
उदाहरण के लिए, आपके पास कोड है:
$.ajax({ url: "ajax/test.html", success: function(data) { alert(data.message); } });
परीक्षणों के लिए अलग ले जाने और कॉलबैक निकालने के बजाय, अजाक्स को पार्स करना बेहतर है। हम फिर से अपने कोड को छूने के बिना लाइब्रेरी एपीआई की तरफ से जाते हैं। हां, निश्चित रूप से, यह jQuery या किसी अन्य लाइब्रेरी को पार्स करना आसान नहीं है और इसे हमारी जांच में "छड़ी" करें, लेकिन आप हमेशा लाइब्रेरी और कोड के बीच अपनी पतली परत लिख सकते हैं। यह न केवल आपको दर्द के बिना परीक्षणों को आगे बढ़ाने और स्टब्स के लिए वास्तविक वस्तुओं का प्रतिस्थापन करने की अनुमति देगा, बल्कि एक अतिरिक्त बोनस के साथ आपको एक फ्रेमवर्क से दूसरे फ्रेम में रोल करने का अवसर मिलेगा।
यह स्पष्ट है कि इस तरह के परीक्षण हडकोर्न थे और केवल कुछ स्पष्ट कीड़े दिखा सकते हैं। लेकिन यह कुछ भी नहीं से बेहतर है। इसके अलावा, उन्हें समर्थन और लिखने के लिए किसी भी प्रयास की आवश्यकता नहीं है। शो के लिए लॉन्च किया गया, सुनिश्चित करें कि सब कुछ काम करने लगे, लिखें। इस तरह के ऑटोटेस्ट्स का एक और प्लस यह है कि आप उन्हें जूनियर सिखा सकते हैं, और जब उन्हें इसकी आदत हो जाती है और परीक्षणों से डरना बंद कर देते हैं, तो सामान्य यूनिट टेस्ट लिखना शुरू करें।
ऑटो प्रलेखन
अपने आप को दस्तावेज बनाना मुश्किल हो सकता है। प्रलेखन लिखने के लिए दूसरों को मजबूर करना लगभग अवास्तविक है। लेकिन आप छोटे से शुरू कर सकते हैं, उचित तर्क दे सकते हैं और ऐसे उपकरण दे सकते हैं जो धीरे-धीरे मदद करेंगे। अपनी आई-फ्री परियोजनाओं में, मैंने एक और समाधान जोड़ा। जैसा कि ऊपर उल्लेख किया गया है, सभी मॉड्यूल के अंत में test.add () है; और आवेदन को शुरू करने के बाद, हमें एक निश्चित सरणी मिलती है जो सभी मॉड्यूल के लिंक को संग्रहीत करती है। आप इस सरणी पर जा सकते हैं, और चूंकि मॉड्यूल ऑब्जेक्ट हैं, उनके पेड़ की रचना करें। उदाहरण के लिए:
module _methodA -> function _methodB -> function _methodC -> function init -> function
और आंकड़ों पर जानकारी भी प्राप्त करें: बाहरी तरीकों की एक सूची, आंतरिक विधियों की एक सूची, आदि। सबसे सरल मामले में, हमें बस इस पेड़ पर हस्ताक्षर करने की आवश्यकता है:
module _methodA -> . _methodB -> . _methodC -> . init -> .
क्योंकि हमारे पास सभी असाइन किए गए इवेंट की सूची तक भी पहुंच है, हम उन्हें फ़िल्टर कर सकते हैं और मॉड्यूल की क्या सुन रहे हैं और क्या प्रकाशित कर रहे हैं, इसकी सूची प्राप्त कर सकते हैं। यह जीवन में कैसा दिखता है, इसका एक उदाहरण:
प्राप्त लॉग के आधार पर, मॉड्यूल का एक संक्षिप्त विवरण बनाया जा सकता है:
इस कोड विश्लेषण के साथ, आप कनिष्ठ को उन बिंदुओं को दिखा सकते हैं, जिन्हें उसे प्रलेखन में वर्णन करना चाहिए और कोड में समझाना चाहिए। मॉड्यूल की संरचना पर एक छोटी नज़र आपको और आपके सहयोगियों को दिखा सकती है कि शायद ऑब्जेक्ट के कुछ तरीकों को आपस में जोड़ा जाना चाहिए, क्योंकि प्रक्रिया को समझने के लिए उनका आदेश कुछ तर्कसंगत नहीं है।