यदि आपका रूबी एप्लिकेशन किसी भी प्रकार के बाहरी एपीआई का उपयोग करता है, तो संभवतः आपको धीमे परीक्षण और API दर सीमा की समस्या का सामना करना पड़ा होगा। ।
समाधान क्या है?
आप अपनी क्लाइंट लाइब्रेरी से HTTP विधियों को मैन्युअल रूप से स्टब कर सकते हैं, और कुछ पूर्व-निर्धारित प्रतिक्रियाएँ लौटा सकते हैं।
लेकिन यह बहुत काम और बदसूरत कोड है!
एक बेहतर उपाय यह है कि वेबमॉक + वीसीआर जैसे रत्नों के शक्तिशाली संयोजन का उपयोग करें ।
WebMock सामान्य HTTP लाइब्रेरी से HTTP अनुरोधों को इंटरसेप्ट करता है, जैसे:
- नेट/http
- फैराडे
- रेस्ट क्लाइंट
- ...और भी बहुत कुछ!
यह अकेले ही उपयोगी है, लेकिन आपको अभी भी प्रतिक्रिया डेटा प्रदान करना होगा।
यहीं पर वीसीआर आता है…
वीसीआर वेबमॉक के साथ संयोजन में काम करता है आपके कोड द्वारा किए गए HTTP प्रतिक्रियाओं को रिकॉर्ड करने के लिए ।
इन रिकॉर्डिंग को "कैसेट" कहा जाता है।
जब आप अपने परीक्षण चलाते हैं :
वीसीआर कैसेट फाइलों को लोड करेगा और रिकॉर्ड की गई प्रतिक्रियाओं को वापस कर देगा। आपको तेज़ प्रतिक्रियाएँ मिलेंगी क्योंकि आपको वास्तविक API पूछने की ज़रूरत नहीं है।
आइए कुछ कोड उदाहरण देखें!
वीसीआर कोड उदाहरण
इस उदाहरण के लिए हम RSpec का उपयोग करने जा रहे हैं क्योंकि यह VCR के साथ बेहतर तरीके से एकीकृत होता है जैसा कि आप अगले भाग में देखेंगे।
यहां वह कोड है जिसका हम परीक्षण करना चाहते हैं :
require "faraday" require "json" class Github def self.user(name) url = "https://api.github.com/users/#{name}" data = Faraday.get(url).body JSON.parse(data, symbolize_names: true) end end
यह एक विशिष्ट उपयोगकर्ता के बारे में जानकारी प्राप्त करने के लिए जीथब एपीआई से अनुरोध करता है। बहुत आसान है लेकिन इससे हमें यह जानने में मदद मिलेगी कि वीसीआर कैसे काम करता है।
इस कोड के लिए एक परीक्षण ऐसा दिखाई दे सकता है :
require "rspec/autorun" require_relative "github_api_example" describe Github do let(:user_response) { Github.user("ruby") } it "can fetch & parse user data" do expect(user_response).to be_kind_of(Hash) expect(user_response).to have_key(:id) expect(user_response).to have_key(:type) end end
यह वास्तविक एपीआई से टकराएगा और पास हो जाएगा, लेकिन इसे समाप्त होने में लगभग आधा सेकंड लगता है।
ONE टेस्ट के लिए आधा सेकंड!
शायद ज्यादा न लगे, लेकिन कल्पना करें कि आपके पास सौ परीक्षण हैं, उन सभी को चलाने के लिए 50 सेकंड हैं।
इसे ठीक करने का समय…
आइए इस बिट कोड को जोड़कर वीसीआर का परिचय दें :
require "vcr" VCR.configure do |c| c.cassette_library_dir = "spec/vcr" c.hook_into :webmock end<ब्लॉकक्वॉट>
आप इस कोड को test_helper
. में जोड़ सकते हैं फ़ाइल, इसलिए यह आपके सभी परीक्षणों के लिए उपलब्ध है
इसके साथ configure
आप वीसीआर को बता रहे हैं कि कैसेट फ़ाइलों को सहेजना है, और वेबमॉक एकीकरण को सक्षम करना है।
यदि आप फैराडे या एक्सकॉन का उपयोग कर रहे हैं, तो वीसीआर सीधे उनसे जुड़ सकता है।
बस :webmock
. को बदलें :faraday
. के साथ , या :excon
।
अगला :
आपको वीसीआर को कैसेट का नाम बताना है और इसके तहत कौन सा कोड चलाना चाहिए।
यहां बताया गया है :
let(:user_response) do VCR.use_cassette("github/user") { Github.user("ruby") } end
जब आप अपने परीक्षण चलाते हैं तो VCR cassette_library_dir
. के अंतर्गत एक फ़ाइल बनाएगा , इस मामले में फ़ाइल का नाम होगा spec/vcr/github/user.yaml
, यदि आप अनुसरण कर रहे हैं तो आप इसे देखना चाहेंगे।
अगर मैं अभी परीक्षण चलाता हूं तो यह बहुत तेज होगा ।
असल में…
इसे समाप्त होने में केवल 0.01 सेकंड लगते हैं!
"एक HTTP अनुरोध किया गया है कि वीसीआर को पता नहीं है कि कैसे संभालना है"
यदि आप इस त्रुटि संदेश में आते हैं तो इसका अर्थ दो चीजों में से एक है:
1.आप वीसीआर सक्षम के साथ एक HTTP कॉल करने का प्रयास कर रहे हैं, लेकिन एक VCR.use_cassette
के बाहर ब्लॉक करें।
समाधान :डिफ़ॉल्ट रूप से VCR + WebMock सभी HTTP अनुरोधों को ब्लॉक कर देता है। आप इसे कॉन्फ़िगरेशन विकल्पों के साथ बदल सकते हैं, लापता वीसीआर ब्लॉक जोड़ सकते हैं, या आरएसपीईसी मेटाडेटा (अगला खंड) का उपयोग कर सकते हैं।
2. आप एक अलग अनुरोध करने का प्रयास कर रहे हैं और एक कैसेट का उपयोग कर रहे हैं जो इस यूआरएल से मेल नहीं खाता है। उदाहरण के लिए, यदि आप अपने परीक्षणों में अनुरोध करते हैं /users/ruby
, यदि आप परीक्षण को /users/apple
में बदलते हैं, तो कैसेट विशेष रूप से इस URL के लिए बनाया जाता है तब आपको यह त्रुटि दिखाई देगी क्योंकि कैसेट किसी भिन्न URL के लिए है।
समाधान :अलग-अलग यूआरएल के लिए अलग-अलग कैसेट का इस्तेमाल करें, new_episodes
को इनेबल करें रिकॉर्डिंग मोड (vcr: { record: :new_episodes }
) या अनुरोध URL को अपडेट करने के बाद पुराने कैसेट को हटा दें।
आरएसपीसी मेटाडेटा का उपयोग कैसे करें
VCR.use_cassette
विधि इस रत्न का उपयोग करने का एक अच्छा तरीका है।
लेकिन…
आप वीसीआर को अपने आप कैसेट बनाने दे सकते हैं।
कैसे?
इसे VCR.configure
. के अंदर जोड़ें ब्लॉक करें:
c.configure_rspec_metadata!
अब आप किसी विशेष परीक्षण के लिए वीसीआर सक्षम कर सकते हैं (it
ब्लॉक), या एक परीक्षण समूह के लिए (describe
)।
इसे पसंद करें :
describe Github, :vcr do # ... end
यह परीक्षण विवरण . के नाम पर कैसेट फ़ाइलें बनाएगा :
spec/vcr/ └── Github ├── can_parse_user_data.yml └── can_test_vcr.yml
ध्यान दें कि यह प्रति परीक्षण एक कैसेट बनाएगा…
भले ही दो परीक्षण एक ही अनुरोध करते हैं और एक ही डेटा का उपयोग करते हैं। वीसीआर उनके लिए अलग कैसेट बनाएगा।
सहायक वीसीआर विकल्प और टिप्स
यदि आप अपने कैसेट के साथ समस्या कर रहे हैं, या यदि आप डेटा का एक नया संस्करण चाहते हैं, तो आप कैसेट फ़ाइलों को हटा सकते हैं ।
VCR नई API प्रतिक्रियाओं को रिकॉर्ड करेगा और इससे आपकी समस्या का समाधान हो सकता है।
लेकिन अगर ऐसा नहीं होता है तो क्या होगा?
आप डीबग मोड को सक्षम कर सकते हैं VCR.configure
. में :
VCR.configure do |c| # ... c.debug_logger = $stderr end
यह बहुत अधिक आउटपुट उत्पन्न कर सकता है, इसलिए अपने परीक्षणों को केवल उन्हीं तक सीमित रखें जिनमें आपकी रुचि है।
अगला :
मान लें कि एपीआई प्रतिक्रिया के हिस्से के रूप में एपीआई कुंजी, या अन्य संवेदनशील डेटा हैं…
आप उस डेटा को रिकॉर्डिंग से फ़िल्टर करना चाह सकते हैं।
यहां बताया गया है :
VCR.configure do |c| # ... c.define_cassette_placeholder("<API_KEY>", ENV["API_KEY"]) end
सारांश
आपने वेबमॉक और वीसीआर रत्नों का उपयोग करना सीख लिया है ताकि आप बाहरी एपीआई प्रतिक्रियाओं की प्रतीक्षा किए बिना अपने रूबी ऐप्स के लिए परीक्षण लिख सकें!
अगर आपको यह पसंद है तो इस लेख को साझा करना न भूलें ताकि अधिक लोग इसका आनंद उठा सकें।
पढ़ने के लिए धन्यवाद