🧓🏽 📗 😹 Rspec के साथ एक ब्लैक बॉक्स के रूप में अपने गो ऐप का परीक्षण करना 🤖 🔨 🤽🏿

अच्छी तरह से लिखे गए परीक्षण एक नई सुविधा जोड़ने या बग को ठीक करने पर एप्लिकेशन को "तोड़ने" के जोखिम को काफी कम कर देते हैं। कई इंटरकनेक्टेड घटकों से युक्त जटिल प्रणालियों में, सबसे आम जमीन का परीक्षण करना सबसे कठिन है।

इस लेख में, मैं इस बारे में बात करूंगा कि कैसे हमने गो पर एक घटक विकसित करते समय अच्छे परीक्षण लिखने में कठिनाई का सामना किया और कैसे हमने रूबी में रूबी में आरएसपीईके लाइब्रेरी का उपयोग करके इस समस्या को हल किया।

प्रोजेक्ट की तकनीक स्टैक पर जाएं

ईटीईएम विकसित करने वाली परियोजनाओं में से एक है, जहां मैं काम करता हूं, इसमें विभाजित किया जा सकता है: व्यवस्थापक पैनल, उपयोगकर्ता खाता, रिपोर्ट जनरेटर और विभिन्न सेवाओं से प्रसंस्करण अनुरोध जिनके साथ हम एकीकृत हैं।

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

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

सेवा को रेल से अलग उदाहरणों के लिए लिखा और तैनात किया गया था। अब, रेल अनुप्रयोगों को तैनात करते समय, आपको यह चिंता नहीं करनी चाहिए कि यह क्वेरी प्रसंस्करण को प्रभावित करेगा। सेवा ने HTTP अनुरोधों को सीधे स्वीकार कर लिया, Ngnix के बिना, थोड़ी मेमोरी का उपयोग किया, किसी तरह से न्यूनतर था।

गो में हमारी यूनिट के परीक्षण में समस्या

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

समाधान विधि

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

निम्नलिखित योजना निकली है:

rspec संकलित करता है और चलते-चलते सेवा शुरू करता है, इसे एक कॉन्फिगरेशन पास करता है, जिसमें टेस्ट बेस तक पहुंच और HTTP अनुरोध प्राप्त करने के लिए एक निश्चित पोर्ट है, उदाहरण के लिए 8082
पोर्ट 8083 पर उस पर प्राप्त HTTP अनुरोधों को रिकॉर्ड करने के लिए एक उपयोगिता भी लॉन्च की गई है
हम RSpec पर साधारण परीक्षण लिखते हैं, अर्थात डेटाबेस में आवश्यक डेटा बनाएं और स्थानीयहोस्ट के लिए एक अनुरोध भेजें: 8082, जैसे कि किसी बाहरी सेवा के लिए, उदाहरण के लिए HTTParty का उपयोग करना
पार्सिम प्रतिक्रिया; डेटाबेस में परिवर्तन की जाँच करें; हम "RequestBin" से रिकॉर्ड किए गए अनुरोधों की सूची प्राप्त करते हैं और उनकी जांच करते हैं।

कार्यान्वयन विवरण:

अब इसे कैसे लागू किया गया इसके बारे में। प्रदर्शन के उद्देश्य से, आइए परीक्षण की गई सेवा का नाम दें: "TheService" और इसके लिए एक आवरण बनाएं:

#/spec/support/the_service.rb #ensure that after all specs TheService will be stopped RSpec.configure do |config| config.after :suite do TheServiceControl.stop end end class TheServiceControl class << self @pid = nil @config = nil def config puts "Please create file: #{config_path}" unless File.exist?(config_path) @config = YAML.load_file(config_path) end def host TheServiceControl.config['server']['addr'] end def config_path Rails.root.join('spec', 'support', 'the_service_config.yml') end def start # will be described below end def stop # will be described below end def post(params, headers) HTTParty.post("http://#{host}/request", body: params, headers: headers ) end end end

बस के मामले में, मैं एक आरक्षण करूँगा कि Rspec में इसे "समर्थन" फ़ोल्डर से ऑटोलॉड फाइलों में कॉन्फ़िगर किया जाना चाहिए:

 Dir[Rails.root.join('spec/support/**/*.rb')].each {|f| require f}

प्रारंभ विधि:

एक अलग विन्यास से TheService स्रोतों के लिए पथ और चलाने के लिए आवश्यक जानकारी पढ़ता है। क्योंकि यह जानकारी अलग-अलग डेवलपर्स से भिन्न हो सकती है, इस कॉन्फिग को Git से बाहर रखा गया है। उसी कॉन्फ़िगरेशन में प्रोग्राम लॉन्च करने के लिए आवश्यक सेटिंग्स शामिल हैं। ये विषम कॉन्फ़िगरेशन एक ही स्थान पर स्थित हैं ताकि अतिरिक्त फ़ाइलों का उत्पादन न हो।
संकलित करता है और "go run {path to main.go} {path to config}" के माध्यम से प्रोग्राम चलाता है और चलाता है
हर सेकंड मतदान, यह तब तक इंतजार करता है जब तक कि चल रहे कार्यक्रम अनुरोधों को स्वीकार करने के लिए तैयार नहीं होते
प्रक्रिया पहचानकर्ता को याद करता है ताकि पुनः आरंभ न हो और इसे रोकने में सक्षम हो।

 #/spec/support/the_service.rb class TheServiceControl #.... def start return unless @pid.nil? puts "TheService starting. " env = config['rails']['env'] cmd = "go run #{config['rails']['main_go']} --config.file=#{config_path}" puts cmd #useful for debug when need run project manually #compile and run Dir.chdir(File.dirname(config['rails']['main_go'])) { @pid = Process.spawn(env, cmd, pgroup: true) } #wait until it ready to accept connections VCR.configure { |c| c.allow_http_connections_when_no_cassette = true } 1.upto(10) do response = HTTParty.get("http://#{host}/monitor") rescue nil break if response.try(:code) == 200 sleep(1) end VCR.configure { |c| c.allow_http_connections_when_no_cassette = false } puts "TheService started. PID: #{@pid}" end #.... end

स्वयं को कॉन्फ़िगर करें:

 #/spec/support/the_service_config.yml server: addr: 127.0.0.1:8082 db: dsn: dbname=project_test sslmode=disable user=postgres password=secret redis: url: redis://127.0.0.1:6379/1 rails: main_go: /home/me/go/src/github.com/company/theservice/main.go recorder_addr: 127.0.0.1:8083 env: PATH: '/home/me/.gvm/gos/go1.10.3/bin' GOROOT: '/home/me/.gvm/gos/go1.10.3' GOPATH: '/home/me/go'

स्टॉप विधि बस प्रक्रिया को रोकती है। नई बात यह है कि माणिक "गो रन" कमांड चलाता है जो एक बच्चे की प्रक्रिया में संकलित बाइनरी चलाता है जिसकी आईडी अज्ञात है। यदि आप माणिक से शुरू की गई प्रक्रिया को रोकते हैं, तो बच्चे की प्रक्रिया अपने आप बंद नहीं होती है और पोर्ट व्यस्त रहता है। इसलिए, प्रक्रिया समूह ID द्वारा रोक होती है:

 #/spec/support/the_service.rb class TheServiceControl #.... def stop return if @pid.nil? print "Stopping TheService (PID: #{@pid}). " Process.kill("KILL", -Process.getpgid(@pid)) res = Process.wait @pid = nil puts "Stopped. #{res}" end #.... end

अब हम एक साझा_संकेत तैयार करेंगे, जहाँ हम डिफ़ॉल्ट चर को परिभाषित करते हैं, यदि शुरू नहीं हुआ है तो TheService शुरू करें और VCR को अस्थायी रूप से अक्षम करें (उनके दृष्टिकोण से, हम एक बाहरी सेवा से बात करते हैं, लेकिन हमारे लिए अब ऐसा नहीं है):

 #spec/support/shared_contexts/the_service_black_box.rb shared_context 'the_service_black_box' do let(:params) do { type: 'save', data: 1 } end let(:headers) { { 'HTTPS' => 'on', 'Content-Type' => 'application/json; charset=utf-8' } } subject(:response) { TheServiceControl.post(params, headers)} before(:all) { TheServiceControl.start } around(:each) do |example| VCR.configure { |c| c.allow_http_connections_when_no_cassette = true } example.run VCR.configure { |c| c.allow_http_connections_when_no_cassette = false } end end

और अब आप स्वयं चश्मा लिखना शुरू कर सकते हैं:

 #spec/requests/the_service/ping_spec.rb require 'spec_helper' describe 'ping request' do include_context 'the_service_black_box' it 'returns response back' do params[:type] = 'ping' params[:data] = '123' parsed_response = JSON.parse(response.body) # make request and parse response expect(parsed_response['error']).to be nil expect(parsed_response['result']).to eq '123' expect(Log.count).to eq 1 #check something in DB end # more specs... end

TheService बाहरी सेवाओं के लिए अपने HTTP अनुरोध कर सकता है। कॉन्फ़िगरेशन का उपयोग करते हुए, हम उन्हें लिखने वाले एक स्थानीय उपयोगिता पर पुनर्निर्देशित करते हैं। इसे शुरू करने और रोकने के लिए एक आवरण भी है, यह "TheServiceControl" वर्ग के समान है, सिवाय इसके कि उपयोगिता बस संकलन के बिना शुरू की जा सकती है।

अतिरिक्त बन्स

गो एप्लिकेशन को लिखा गया था ताकि सभी लॉग और डीबगिंग जानकारी STDOUT में प्रदर्शित हो। उत्पादन में लॉन्च होने पर, यह आउटपुट एक फ़ाइल में भेजा जाता है। और जब Rspec से लॉन्च किया जाता है, तो यह कंसोल में प्रदर्शित होता है, जो डीबगिंग करते समय बहुत मदद करता है।

यदि ऐनक चयनात्मक रूप से चलाया जाता है, जिसके लिए TheService की आवश्यकता नहीं है, तो यह शुरू नहीं होता है।

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

निष्कर्ष

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