स्वच्छ स्विफ्ट वास्तुकला में इकाई परीक्षण

नमस्कार पाठक जी!

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

सिद्धांत

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

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

निष्पक्षता में, मैं यह जोड़ता हूं कि टेस्ट ऑब्जेक्ट ( टेस्ट डबल्स ) डमी , फेक , स्टब और मॉक भी हैं । लेकिन इस लेख के ढांचे के भीतर, हम उन्हें प्रभावित नहीं करेंगे। यहाँ और पढ़ें - TestDoubles

अभ्यास

शब्दों के साथ समाप्त, चलो व्यापार के लिए नीचे उतरो। अपना समय बचाने के लिए, हम प्रत्येक विधि के कार्यान्वयन के विवरण में जाए बिना सार कोड पर विचार करेंगे। एप्लिकेशन कोड का विवरण यहां पाया जा सकता है: CleanSwiftTests

दृश्य के प्रत्येक घटक के लिए, हम घटक निर्भरता ( टेस्ट डबल्स ) के लिए परीक्षण और परीक्षण डबल्स के साथ एक फ़ाइल बनाते हैं।

इस तरह की संरचना का एक उदाहरण:

प्रत्येक परीक्षण फ़ाइल की संरचना (घटकों के लिए) समान दिखती है और लेखन के निम्नलिखित अनुक्रम का पालन करती है:

• हम SUT के साथ एक चर घोषित करते हैं (जिस वस्तु का हम परीक्षण करने जा रहे हैं) और इसकी मुख्य निर्भरता वाले चर
• हम सेट ( और ) में SUT और उसकी निर्भरता को इनिशियलाइज़ करते हैं, और फिर उन्हें आंसू में साफ़ करते हैं ()
• टेस्ट के तरीके

जैसा कि हमने सिद्धांत पर चर्चा की, दृश्य के प्रत्येक घटक को अलग से परीक्षण किया जा सकता है। हम परीक्षण डुप्लिकेट ( स्पाई ) को उसकी निर्भरता में इंजेक्ट कर सकते हैं और इस तरह हमारे SUT के तरीकों के संचालन की निगरानी कर सकते हैं। होम दृश्य के इंटरेक्टर उदाहरण का उपयोग करके परीक्षण लिखने की प्रक्रिया पर करीब से नज़र डालते हैं।

HomeInteractor दो वस्तुओं पर निर्भर है - प्रस्तुतकर्ता और कार्यकर्ता । कक्षा में दोनों चर में एक प्रोटोकॉल प्रकार होता है। इसका अर्थ है कि हम HomePresentationLogic और HomeWorkingLogic प्रोटोकॉल के तहत हस्ताक्षरित टेस्ट डुप्लिकेट बना सकते हैं, और फिर उन्हें HomeInteractor में इंजेक्ट कर सकते हैं ।

final class HomeInteractor: HomeBusinessLogic, HomeDataStore { // MARK: - Public Properties var presenter: HomePresentationLogic? lazy var worker: HomeWorkingLogic = HomeWorker() var users: [User] = [] var selectedUser: User? // MARK: - HomeBusinessLogic func fetchUsers(_ request: HomeModels.FetchUsers.Request) { // ... } func selectUser(_ request: HomeModels.SelectUser.Request) { // ... } 

हम दो तरीकों का परीक्षण करेंगे:

• fetchUsers (:) । एपीआई द्वारा उपयोगकर्ताओं की सूची प्राप्त करने के लिए जिम्मेदार। कार्यकर्ता का उपयोग करके एक एपीआई अनुरोध भेजा जाता है।
• चयनकर्ता (:) लोड किए गए उपयोगकर्ताओं ( उपयोगकर्ताओं ) की सूची से सक्रिय उपयोगकर्ता ( चयनित उपयोगकर्ता) का चयन करने के लिए जिम्मेदार।

इंटरेक्टर के परीक्षण लिखना शुरू करने के लिए, हमें उन जासूसों को बनाने की आवश्यकता है जो HomePresentationLogic और HomeWorkingLogic में विधियों के आह्वान को ट्रैक करेंगे। ऐसा करने के लिए, 'CleanSwiftTestsTests / Stores / Home / TestDoubles / Spies' निर्देशिका में HomePresentationLogicSpy वर्ग बनाएं, प्रोटोकॉल HomePresentationLogic पर हस्ताक्षर करें और इस प्रोटोकॉल की विधि को लागू करें।

 final class HomePresentationLogicSpy: HomePresentationLogic { // MARK: - Public Properties private(set) var isCalledPresentFetchedUsers = false // MARK: - Public Methods func presentFetchedUsers(_ response: HomeModels.FetchUsers.Response) { isCalledPresentFetchedUsers = true } } 

यहां सब कुछ बेहद पारदर्शी है। यदि PresentFetchedUsers ( HomePresentationLogic ) विधि को कॉल किया गया था, तो हम isCalledPresentFetchedUser चर का मान सही पर सेट करते हैं। इस प्रकार, हम यह ट्रैक कर सकते हैं कि क्या इस विधि को इंटरेक्टर के परीक्षण के दौरान बुलाया गया था।

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

 final class HomeWorkingLogicSpy: HomeWorkingLogic { // MARK: - Public Properties private(set) var isCalledFetchUsers = false let users: [User] = [ User(id: 1, name: "Ivan", username: "ivan91"), User(id: 2, name: "Igor", username: "igor_test") ] // MARK: - Public Methods func fetchUsers(_ completion: @escaping ([User]?) -> Void) { isCalledFetchUsers = true completion(users) } } 

अगला, हम HomeInteractorTests वर्ग बनाते हैं, जिसके साथ हम HomeInteractor का परीक्षण करेंगे ।

 final class HomeInteractorTests: XCTestCase { // MARK: - Private Properties private var sut: HomeInteractor! private var worker: HomeWorkingLogicSpy! private var presenter: HomePresentationLogicSpy! // MARK: - Lifecycle override func setUp() { super.setUp() let homeInteractor = HomeInteractor() let homeWorker = HomeWorkingLogicSpy() let homePresenter = HomePresentationLogicSpy() homeInteractor.worker = homeWorker homeInteractor.presenter = homePresenter sut = homeInteractor worker = homeWorker presenter = homePresenter } override func tearDown() { sut = nil worker = nil presenter = nil super.tearDown() } // MARK: - Public Methods func testFetchUsers() { // ... } func testSelectUser() { // ... } } 

हम तीन मुख्य चर इंगित करते हैं - sut , कार्यकर्ता और प्रस्तुतकर्ता ।

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

सेटअप () विधि को परीक्षण विधि शुरू होने से पहले कहा जाता है, उदाहरण के लिए testFetchUsers () , और tearDown () जब इस विधि ने अपना काम पूरा किया है। इस प्रकार, हम प्रत्येक परीक्षण विधि को चलाने से पहले परीक्षण ऑब्जेक्ट ( sut ) को फिर से बनाते हैं।

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

 func testFetchUsers() { let request = HomeModels.FetchUsers.Request() sut.fetchUsers(request) XCTAssertTrue(worker.isCalledFetchUsers, "Not started worker.fetchUsers(:)") XCTAssertTrue(presenter.isCalledPresentFetchedUsers, "Not started presenter.presentFetchedUsers(:)") XCTAssertEqual(sut.users.count, worker.users.count) } 

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

 func testSelectUser() { let expectationId = 2 let expectationName = "Vasya" let users = [ User(id: 1, name: "Ivan", username: "ivan"), User(id: 2, name: "Vasya", username: "vasya91"), User(id: 3, name: "Maria", username: "maria_love") ] let request = HomeModels.SelectUser.Request(index: 1) sut.users = users sut.selectUser(request) XCTAssertNotNil(sut.selectedUser, "User not selected") XCTAssertEqual(sut.selectedUser?.id, expectationId) XCTAssertEqual(sut.selectedUser?.name, expectationName) } 

परीक्षण प्रस्तुतकर्ता और ViewController'a एक ही सिद्धांत पर होता है, जिसमें न्यूनतम अंतर होता है। एक अंतर यह है कि ViewController का परीक्षण करने के लिए , आपको एक UIWindow बनाने और setUp () में स्टोरीबोर्ड से नियंत्रक प्राप्त करने की आवश्यकता होगी, साथ ही टेबल और संग्रह पर स्पाई ऑब्जेक्ट भी बनाएंगे। लेकिन ये बारीकियां जरूरतों से भिन्न होती हैं।

पूर्णता के लिए, मेरा सुझाव है कि आप लेख के अंत में लिंक द्वारा परियोजना के साथ खुद को परिचित करें।

निष्कर्ष

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

परियोजना के लिए लिंक: CleanSwiftTests
एक लेख लिखने में मदद: बास्टियन

लेखों की श्रृंखला

1. स्वच्छ स्विफ्ट वास्तुकला अवलोकन
2. स्वच्छ स्विफ्ट वास्तुकला में राउटर और डेटा पासिंग
3. क्लीन स्विफ्ट आर्किटेक्चर में श्रमिक
4. स्वच्छ स्विफ्ट वास्तुकला में इकाई परीक्षण (आप यहां हैं)
5. एक सरल ऑनलाइन स्टोर आर्किटेक्चर क्लीन स्विफ्ट का एक उदाहरण