मेमोरी लीक की जांच के लिए एकीकरण परीक्षण

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

मेमोरी लीक्स

कभी-कभी मेमोरी लीक की त्रुटि का पता लगाना काफी मुश्किल होता है। प्रतिनिधि के लिए एक मजबूत संदर्भ होने की संभावना है, लेकिन ऐसी त्रुटियां भी हैं जिनका पता लगाना अधिक कठिन है। उदाहरण के लिए, क्या यह स्पष्ट है कि निम्नलिखित कोड में मेमोरी रिसाव हो सकता है?

final class UseCase { weak var delegate: UseCaseDelegate? private let service: Service init(service: Service) { self.service = service } func run() { service.makeRequest(handleResponse) } private func handleResponse(response: ServiceResponse) { // some business logic and then... delegate.operationDidComplete() } } 

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

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

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

इस VIPER मॉड्यूल में कई प्रतिनिधि, पर्यवेक्षक और भगोड़े दोष हो सकते हैं, जिनमें से प्रत्येक नेविगेशन स्टैक से हटाए जाने के बाद नियंत्रक को स्मृति में बने रहने का कारण बन सकता है। जब ऐसा होता है, तो मेमोरी की मात्रा बढ़ जाएगी, और ऑपरेटिंग सिस्टम अच्छी तरह से एप्लिकेशन को रोकने का निर्णय ले सकता है।

तो क्या यह संभव है कि कुछ इकाई परीक्षणों को संभव के रूप में लिखकर इतने संभावित लीक को कवर किया जाए? यदि नहीं, तो यह सब समय की भारी बर्बादी थी।

एकीकरण परीक्षण

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

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

पहली समस्या जिसका हम सामना कर रहे हैं, वह यह है कि प्रकृति द्वारा हम आसानी से UIViewController के अलावा VIPER मॉड्यूल के किसी भी हिस्से तक नहीं पहुंच सकते हैं। हमारे ModuleFactory में एकमात्र सार्वजनिक कार्य है फंक मेक () -> UIViewController । लेकिन क्या होगा यदि हम केवल अपने परीक्षणों के लिए एक और प्रविष्टि बिंदु जोड़ते हैं? इस नई पद्धति को आंतरिक के माध्यम से घोषित किया जाएगा, इसलिए हम केवल @ आयात करने योग्य मॉड्यूल मॉड्यूलवर्क के माध्यम से इसे एक्सेस कर सकते हैं। यह मॉड्यूल के सभी सबसे महत्वपूर्ण हिस्सों के लिंक लौटाएगा, जिसे हम अपने परीक्षण में दर्ज करने के लिए कमजोर लिंक पकड़ सकते हैं। यह अंततः इस तरह दिखता है:

 public final class ModuleFactory { //     ,   ... public func make() -> UIViewController { makeAndExpose().view } typealias ModuleComponents = ( view: UIViewController, presenter: Presenter, Interactor: Interactor ) func makeAndExpose() -> ModuleComponents { // Set up code, and then... return ( view: viewController, presenter: presenter, interactor: interactor ) } } 

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

 final class ModuleMemoryLeakTests: XCTestCase { //      .     //    . private var view: UIViewController? //        //   ,    // UIKit,   UIViewController  . private weak var presenter: Presenter? private weak var interactor: Interactor? //   setUp    ModuleFactory  //   makeAndExpose.     ,   //     ModuleComponents // ,          . //     . func setUp() { super.setUp() let moduleFactory = ModuleFactory(/* mocked dependencies & config */) let components = moduleFactory.makeAndExpose() view = components.view presenter = components.presenter interactor = components.interactor } //   ,   tearDown   , //        ,     ,   //     . func tearDown() { view = nil presenter = nil interactor = nil super.tearDown() } func test_module_doesNotLeakMemory() { //   ,      . //      ,  //          setUp. XCTAssertNotNil(presenter) XCTAssertNotNil(interactor) //        . //    ,   //     ,    //      . view = nil // ,  ,    //  Presenter  Interactor   . //  ,       //  ,    . XCTAssertNil(presenter) XCTAssertNil(interactor) } } 

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

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