उंगलियों पर रेल का परिचय (रेल + आरपीईसी)

मेरे लिए व्यक्तिगत रूप से, बल्कि एक बहुत ही विकसित डेवलपर, टीडीडी को लागू करने की प्रक्रिया कठिन और कभी-कभी कांटेदार थी।

मैं संक्षेप में उल्लिखित करूंगा, क्योंकि परीक्षण में प्रवेश करने की दहलीज वास्तव में केवल बैठकर और RoR पर कोड लिखने की तुलना में अधिक है। मैं कुछ करूंगा, जैसा कि पिंडोस लिखते हैं, हाइलाइट्स।

सैद्धांतिक रूप से, TDD प्रक्रिया को इस तरह दिखना चाहिए:

1. एक गिरते परीक्षण को लिखा, rspec चलाई, यह सुनिश्चित किया कि परीक्षण विफल (लाल)

2. हमने कोड का एक टुकड़ा लिखा, rspec चलाई, सुनिश्चित किया कि परीक्षण पास (हरा)

3. Refactored, सुनिश्चित करें कि सब कुछ ठीक है और परीक्षण विफल नहीं होते हैं।

4. उत्पादन के लिए कोड भेजा गया



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

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

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

इन सभी तकनीकों के लिए एक अच्छी फ़ाइल की भी आवश्यकता होती है। क्या समय पर, यदि यह स्टैकफ़्लो के लिए नहीं था, तो मुझे TDD का उपयोग करने से निराशा होगी:

ex: stackoverflow.com/questions/8303491/how-do-i-make-sure-the-helpers-and-models-reload-in-rspec-when-im-use-spork

खुद को परख रहा है

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

हमेशा की तरह, लोग तीन तरीकों से परीक्षण कर रहे हैं।

1. मॉडल परीक्षण, या इकाई परीक्षण

यहां हम मॉडल में विधियों की शुद्धता, मान्यताओं की वैधता की जांच करते हैं।

validate_presence_of (: मॉडल) rspec सेनानी के साथ नहीं आता है, इसलिए आपको कंधा लगाना और कनेक्ट करना होगा

gem "shoulda-matchers"

और आगे spec_helper.rb में

require 'shoulda-matchers'

2. नियंत्रक परीक्षण, या जैसा कि उन्हें भी कहा जाता है, कार्यात्मक

चीजों की जाँच की जाती है ताकि वास्तव में एक वस्तु का निर्माण हो या 'नया' इत्यादि का प्रतिपादन हो

एक नमूना परीक्षण में एक नियंत्रक कॉल शामिल होगी

post :create, mymodel: param1

और परिणामों की जाँच कर रहा है। उदाहरण के लिए, असाइनमेंट नियंत्रक विधि में निर्दिष्ट किए जाने चाहिए

assigns(:mymodel){ should == MyModel.last }

सुनिश्चित करें कि नया टेम्पलेट प्रदान किया गया है। यह स्पष्ट है, लेकिन सहज नहीं है।

response.should render_template('new')

3. एकीकरण परीक्षण, कहानियों में सुधार

BDD का इतिहास यह है कि ग्राहक की भाषा में अनुवाद में ग्राहक की नज़र में यह सुविधा कैसी है। आमतौर पर, एक कहानी एक वर्णन और एक ही विशेषता के परीक्षण के लिए कोड का एक टुकड़ा है।

यह एक ककड़ी पैराफेरेस से अधिक है, हालांकि, बेस इंस्टॉलेशन में rspec एक कल्पना / अनुरोध / फ़ोल्डर भी बनाता है, जहां एकीकरण परीक्षण रखे जाते हैं।

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

इसलिए, एकीकरण परीक्षण ब्राउज़र एमुलेशन का उपयोग करके क्रियाओं की श्रृंखला चलाता है।

सबसे अधिक बार, इस तरह के बकवास काम करते हैं यदि मणि कैपीबारा या वेब्रैट जुड़े हुए हैं, जो वास्तव में ब्राउज़र अनुकरण करते हैं

परीक्षण आमतौर पर इस तरह दिखता है:

• फ़ील्ड 1 को डेटा 1 के साथ भरें
• राजकुमार को धक्का देना
• जाँचें कि डेटा रिकॉर्ड 1 पृष्ठ पर दिखाई दिया

इस कोड की तरह कुछ

visit services_path

page.should have_content(" ")


यात्रा और has_content हम capybara heme से प्राप्त करते हैं।

क्या और कैसे परीक्षण करना है, इसके बारे में थोड़ा। आपको सीमा मामलों की जांच करनी चाहिए, उदाहरण के लिए, यदि कोड उपयोगकर्ता बनाना है, तो इसे दो परीक्षणों के साथ जांचें:

1. उपयोगकर्ता सही ढंग से बनाया गया है, हम जांचते हैं कि रिकॉर्ड डेटाबेस में दिखाई दिया है।

2. अगर उपयोगकर्ता सही तरीके से नहीं बना है तो हमें वास्तव में एक त्रुटि मिलती है।

हर कोई जो पहले से ही परीक्षण कर रहा है, अच्छी तरह से किया है, लेकिन हर किसी ने जो अभी तक नहीं किया है, मैं शुरू करने की सलाह देता हूं।