कोड परीक्षण क्षमता, कार्यान्वयन उदाहरण में सुधार के लिए डि का उपयोग करके कनेक्टिविटी के स्तर को कम करना

लेख की शुरुआत में मैं तुरंत ध्यान देना चाहता हूं कि मैं नया होने का दिखावा नहीं करता, लेकिन केवल IoC DI जैसे अवसर को साझा / याद करना चाहता हूं।

इसके अलावा, मेरे पास लेख लिखने का कोई अनुभव नहीं है, यह मेरा पहला है। यदि आपने कड़ाई से न्याय नहीं किया तो मैंने अपनी ओर से पूरी कोशिश की।

हम किस बारे में बात कर रहे हैं

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

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

इसके अलावा, प्रोग्रामर के सिर में एक तार्किक श्रृंखला बनती है, लेकिन मुझे व्यवसाय तर्क कोड को किसी अन्य स्तर पर स्थानांतरित करने की आवश्यकता क्यों है, मैं यहां सिर्फ कुछ लाइनें जोड़ूंगा और सब कुछ ग्राहक की आवश्यकताओं को पूरा करेगा।

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

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

रूबी परियोजनाओं में इसे कैसे हल किया जाए, इसका सामान्य विचार

मूल विचार यह है कि जिन वस्तुओं पर निर्भरता होती है, हमें उनका प्रबंधन करने में सक्षम होना चाहिए।

एक उदाहरण पर विचार करें:

class UserService def initialize() @notification_service = NotificationService.new end def block_user(user) user.block! @notification_service.send(user, 'you have been blocked') end end 

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

 class UserService def initialize(notification_service = NotificationService.new) @notification_service = notification_service end def block_user(user) user.block! @notification_service.send(user, 'you have been blocked') end end 

अब, जब परीक्षण करते हैं, तो हम एक ऑब्जेक्ट को NotificationService मॉक के रूप में पास करते हैं, और सत्यापित करते हैं कि block_user सही क्रम में और सही तर्कों के साथ अधिसूचना_ सेवा विधियों को खींचता है।

 RSpec.describe UserService, type: :service do let (:notification_service) { instance_double(NotificationService) } let (:service) { UserService.new(notification_service) } describe ".block_user" do let (:user) { instance_double(User) } it "should block user and send notification" do expect(user).to receive :block! expect(notification_service).to receive(:send).with(user, "you have been blocked") service.block_user(user) end end end 

रेल के लिए केस स्टडी

जब सिस्टम में बहुत सारे सर्विस ऑब्जेक्ट होते हैं, तो सभी निर्भरताएं स्वयं बनाना मुश्किल हो जाता है, कोड कोड की अतिरिक्त लाइनों के साथ बढ़ने लगता है जो पठनीयता को कम करते हैं।

इस संबंध में, यह मेरे लिए एक छोटा मॉड्यूल लिखने के लिए हुआ जो निर्भरता प्रबंधन को स्वचालित करता है।

 module Services module Injector def self.included(base) # TODO: check base, should be controller or service base.extend ClassMethods end module ClassMethods def inject_service(name) service = Services::Helpers::Service.new(name) attr_writer service.to_s define_method service.to_s do instance_variable_get("@#{service.to_s}").tap { |s| return s if s } instance_variable_set("@#{service.to_s}", service.instance) end end end end module Helpers class Service def initialize(name) raise ArgumentError, 'name of service should be a Symbol' unless name.is_a? Symbol @name = name.to_s.downcase @class = "#{@name.camelcase}Service".constantize unless @class.respond_to? :instance raise ArgumentError, "#{@name.to_s} should be singleton (respond to instance method)" end end def to_s "#{@name}_service" end def instance if Rails.env.test? if defined? RSpec::Mocks::ExampleMethods extend RSpec::Mocks::ExampleMethods instance_double @class else nil end else @class.instance end end end end end 

एक कैविएट है, सेवा सिंगलटन होनी चाहिए, अर्थात्। एक उदाहरण विधि है। ऐसा करने का सबसे आसान तरीका सेवा वर्ग include Singleton ।

अब ApplicationController ऐड में

 require 'services' class ApplicationController < ActionController::Base include Services::Injector end 

और अब कंट्रोलर्स में हम ऐसा कर सकते हैं

 class WelcomeController < ApplicationController inject_service :welcome def index render plain: welcome_service.text end end 

इस नियंत्रक की कल्पना में, हम स्वचालित रूप से एक निर्भरता के रूप में inst_double (WelcomeService) प्राप्त करते हैं।

 RSpec.describe WelcomeController, type: :controller do describe "index" do it "should render text from test service" do allow(controller.welcome_service).to receive(:text).and_return "OK" get :index expect(response).to have_attributes body: "OK" expect(response).to have_http_status 200 end end end 

क्या सुधार किया जा सकता है

उदाहरण के लिए, कल्पना करें कि हमारे सिस्टम में कई विकल्प हैं कि हम कैसे सूचनाएं भेज सकते हैं, उदाहरण के लिए, रात में यह एक प्रदाता होगा, और दिन के दौरान एक और। इसी समय, प्रदाताओं के पास भेजने वाले प्रोटोकॉल पूरी तरह से अलग हैं।

सामान्य तौर पर, NotificationService इंटरफ़ेस समान रहता है, लेकिन दो विशिष्ट कार्यान्वयन हैं।

 class NightlyNotificationService < NotificationService end class DailyNotificationService < NotificationService end 

अब हम एक वर्ग लिख सकते हैं जो सेवाओं की सशर्त मानचित्रण करेगा

 class NotificationServiceMapper include Singleton def take now = Time.now ((now.hour >= 00) and (now.hour <= 8)) ? NightlyNotificationService : DailyNotificationService end end 

अब जब हम सेवा में उदाहरण लेते हैं :: Helpers :: Service.instance हमें यह जांचने की आवश्यकता है कि क्या कोई * Mapper ऑब्जेक्ट है, और यदि ऐसा है, तो क्लास को टेक के माध्यम से स्थिर रखें।