🌘 👨🏿‍⚕️ ◻️ क्यों यूनिट परीक्षणों का उपयोग गुणवत्ता वास्तुकला में एक महान निवेश है 🤠 👩🏻‍🔧 🕎

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

निर्भरता अलगाव - इकाई परीक्षण आधार

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

स्पष्टता के लिए उदाहरण

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

//     C#.  1. public class MessagingService { public void SendMessage(Guid messageAuthorId, Guid messageRecieverId, string message) { //        new MessagesRepository().SaveMessage(messageAuthorId, messageRecieverId, message); //,     if (UsersService.IsUserOnline(messageRecieverId)) { //  ,     NotificationsService.SendNotificationToUser(messageAuthorId, messageRecieverId, message); } } }

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

 //     C#.  2. public class MessagingService: IMessagingService { private readonly IUserService _userService; private readonly INotificationService _notificationService; private readonly IMessagesRepository _messagesRepository; public MessagingService(IUserService userService, INotificationService notificationService, IMessagesRepository messagesRepository) { _userService = userService; _notificationService = notificationService; _messagesRepository = messagesRepository; } public void AddMessage(Guid messageAuthorId, Guid messageRecieverId, string message) { //        _messagesRepository.SaveMessage(messageAuthorId, messageRecieverId, message); //,     if (_userService.IsUserOnline(messageRecieverId)) { //   _notificationService.SendNotificationToUser(messageAuthorId, messageRecieverId, message); } } }

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

हम संदेश भेजने वाले मॉड्यूल के लिए एक परीक्षण लिख रहे हैं

परीक्षण विनिर्देश

हम निर्धारित करते हैं कि वास्तव में हमारे परीक्षण को क्या जांचना चाहिए।

IMessageRepository.SaveMessage पद्धति के लिए एकल कॉल का तथ्य
INUificationsService.SendNotificationToUser () विधि के लिए एक एकल कॉल का तथ्य, यदि IsUserOnline () विधि IUserService ऑब्जेक्ट पर स्टब्स सही लौटे
कॉलिंग की कमी INOTificationsService.SendNotificationToUser () विधि, यदि IsUserOnline () विधि IUserService ऑब्जेक्ट पर ठूंठ गलत है

इन तीन शर्तों को पूरा करने से यह सुनिश्चित होता है कि SendMessage पद्धति का कार्यान्वयन सही है और त्रुटि मुक्त है।

परीक्षण

Moq आइसोलेशन फ्रेमवर्क का उपयोग करके परीक्षण को लागू किया गया है।

 [TestMethod] public void AddMessage_MessageAdded_SavedOnce() { //Arrange // Guid messageAuthorId = Guid.NewGuid(); //,   Guid recieverId = Guid.NewGuid(); //,     string msg = "message"; //    IsUserOnline  IUserService Mock<IUserService> userServiceStub = new Mock<IUserService>(new MockBehavior()); userServiceStub.Setup(x => x.IsUserOnline(It.IsAny<Guid>())).Returns(true); //  INotificationService  IMessagesRepository Mock<INotificationService> notificationsServiceMoq = new Mock<INotificationService>(); Mock<IMessagesRepository> repositoryMoq = new Mock<IMessagesRepository>(); //  ,         var messagingService = new MessagingService(userServiceStub.Object, notificationsServiceMoq.Object, repositoryMoq.Object); //Act messagingService.AddMessage(messageAuthorId, recieverId, msg); //Assert repositoryMoq.Verify(x => x.SaveMessage(messageAuthorId, recieverId, msg), Times.Once); } [TestMethod] public void AddMessage_MessageSendedToOffnlineUser_NotificationDoesntRecieved() { //Arrange // Guid messageAuthorId = Guid.NewGuid(); //   Guid offlineReciever = Guid.NewGuid(); //,     string msg = "message"; //    IsUserOnline  IUserService Mock<IUserService> userServiceStub = new Mock<IUserService>(new MockBehavior()); userServiceStub.Setup(x => x.IsUserOnline(offlineReciever)).Returns(false); //  INotificationService  IMessagesRepository Mock<INotificationService> notificationsServiceMoq = new Mock<INotificationService>(); Mock<IMessagesRepository> repositoryMoq = new Mock<IMessagesRepository>(); //  ,         var messagingService = new MessagingService(userServiceStub.Object, notificationsServiceMoq.Object, repositoryMoq.Object); //Act messagingService.AddMessage(messageAuthorId, offlineReciever, msg); //Assert notificationsServiceMoq.Verify(x => x.SendNotificationToUser(messageAuthorId, offlineReciever, msg), Times.Never); } [TestMethod] public void AddMessage_MessageSendedToOnlineUser_NotificationRecieved() { //Arrange // Guid messageAuthorId = Guid.NewGuid(); //,   Guid onlineRecieverId = Guid.NewGuid(); //,     string msg = "message"; //    IsUserOnline  IUserService Mock<IUserService> userServiceStub = new Mock<IUserService>(new MockBehavior()); userServiceStub.Setup(x => x.IsUserOnline(onlineRecieverId)).Returns(true); //  INotificationService  IMessagesRepository Mock<INotificationService> notificationsServiceMoq = new Mock<INotificationService>(); Mock<IMessagesRepository> repositoryMoq = new Mock<IMessagesRepository>(); //  ,         var messagingService = new MessagingService(userServiceStub.Object, notificationsServiceMoq.Object, repositoryMoq.Object); //Act messagingService.AddMessage(messageAuthorId, onlineRecieverId, msg); //Assert notificationsServiceMoq.Verify(x => x.SendNotificationToUser(messageAuthorId, onlineRecieverId, msg), Times.Once); }

सही वास्तुकला ढूँढना - एक व्यर्थ व्यायाम

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

क्यों यूनिट परीक्षणों का उपयोग गुणवत्ता वास्तुकला में एक महान निवेश है

निर्भरता अलगाव - इकाई परीक्षण आधार

स्पष्टता के लिए उदाहरण

हम संदेश भेजने वाले मॉड्यूल के लिए एक परीक्षण लिख रहे हैं

सही वास्तुकला ढूँढना - एक व्यर्थ व्यायाम

More articles: