परीक्षण @ NonNull / @ अशक्त एनोटेशन

इसके बदले "समर्पित ..."

नीचे वर्णित कार्य अभिनव या बहुत उपयोगी नहीं था, जिस कंपनी में मैं काम करता हूं, उसे इसके लिए लाभ नहीं मिलेगा, लेकिन मैं एक बोनस होगा।

लेकिन यह कार्य था, और इसलिए इसे हल किया जाना था।

पहचान

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

लेकिन वर्तमान परियोजना पर, उल्लिखित पुस्तकालय मौजूद है, और कुछ मुझे बताता है कि हमारी परियोजना केवल एक ही नहीं है।
तो यहाँ है।

जावा में अंतिम बार एनोटशकी की ओर एक प्रवृत्ति है। तेजी से असफल होने की अवधारणा की महिमा के लिए, तरीकों के मापदंडों को अक्सर एनोटेशन @ नोनल के साथ एनोटेट किया जाता है (ताकि अगर कुछ गलत हो जाए, तो यह पता चला )।

इसके लिए बहुत सारे आयात विकल्प हैं (या विचारधारा में समान व्याख्या), लेकिन, जैसा कि यह पहले ही स्पष्ट हो चुका है, हम संस्करण पर ध्यान केंद्रित करेंगे

import lombok.NonNull; 

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

एक इकाई परीक्षण के साथ इस एनोटेशन का परीक्षण करना काफी सरल है, समस्या यह है कि ऐसे परीक्षण वसंत में खरगोशों की गति से आपकी परियोजना में गुणा करेंगे, और खरगोश, जैसा कि आप जानते हैं, DRY सिद्धांत का उल्लंघन करते हैं।

लेख में हम @NonNull एनोटेशन के अनुबंध के परीक्षण के लिए एक छोटा सा परीक्षण ढाँचा लिखेंगे (और ताकि सोनार आपकी आँखों में लालिमा न बिखेरे)।

PS गीत का नाम पॉवरवॉल्फ बैंड के गीत से प्रेरित था, जो मैंने (मूल रूप से) लिखा था, जब मैंने नाम लिखा था (मूल में, नाम अधिक सकारात्मक लगता है)

मुख्य शरीर

प्रारंभ में, हमने एनोटेशन का परीक्षण कुछ इस तरह किया:

 @Test void methodNameWithNullArgumentThrowException() { try { instance.getAnyType(null); fail("Exception not thrown"); } catch (final NullPointerException e) { assertNotNull(e); } } 

उन्होंने विधि को बुलाया और @NonNull एनोटेशन के साथ एनोटेट के रूप में एक पैरामीटर पास किया।
उन्हें एनपीई मिला और वे संतुष्ट हुए (सोनार भी खुश थे)।

फिर उन्होंने ऐसा ही करना शुरू कर दिया, लेकिन एक और अधिक फैशनेबल मुखर के साथ जो आपूर्तिकर्ता के माध्यम से काम करता है (हम लंबोदर से प्यार करते हैं):

 @TestUnitRepeatOnce void methodNameWithNullArgumentThrowException() { assertThrows(NullPointerException.class, () -> instance.getAnyType(null)); } 

स्टाइलिश। फैशनेबल। युवा।

यह खत्म करना संभव होगा, एनोटेशन का परीक्षण किया जाता है, तो क्या अधिक है?

इस परीक्षण विधि की समस्या (नहीं है कि समस्या है, लेकिन अभी भी) "सामने" जब एक दिन मैंने एक विधि के लिए एक परीक्षण लिखा, तो यह सफलतापूर्वक काम किया, और फिर मैंने देखा कि पैरामीटर पर कोई @ नोनल एनोटेशन नहीं है।

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

यह पता चला है कि हम इस मामले में परीक्षण कर रहे हैं, एनोटेशन नहीं, लेकिन यह स्पष्ट नहीं है कि क्या है। परीक्षण सही ढंग से काम करने के साथ, हमें इस विधि में गहराई तक नहीं जाना चाहिए (थ्रेशोल्ड पर गिरते हुए)।
@ लोनोक के एननॉल एनोटेशन में एक विशेषता है: यदि हम एनपीई से एनोटेशन तक आते हैं, तो पैरामीटर नाम त्रुटि के लिए लिखा जाता है।

हम इसमें शामिल हो जाएंगे, जब हम एनपीई से गिर जाते हैं, हम इसके बाद स्टैकट्रेस के पाठ की जांच करेंगे, जैसे:

 exception.getCause().getMessage().equals(parameter.getName()) 

सब कुछ कुछ नहीं लगता है, अब हम वास्तव में जांचते हैं कि क्या जरूरत है, लेकिन "खरगोश" की समस्या हल नहीं हुई है।

मैं एक ऐसा उपकरण लेना चाहूंगा जिसे कहा जा सके, उदाहरण के लिए, इस तरह:

 @TestUnitRepeatOnce @SneakyThrows void nonNullAnnotationTest() { assertNonNullAnnotation(YourPerfectClass.class); } 

और वह स्वयं जाकर निर्दिष्ट वर्ग के सभी सार्वजनिक तरीकों को स्कैन करेगा और एक परीक्षण के साथ अपने सभी @NonNull मापदंडों की जाँच करेगा।

आप कहेंगे, एक प्रतिबिंब प्राप्त करें, और जांच लें कि क्या विधि @ नोनल चालू है और यदि इसमें कोई गोली है या नहीं।

सभी कुछ भी नहीं होगा, लेकिन RetentionPolicy समान नहीं है।

सभी एनोटेशन में एक रिटेंशनपॉलिश पैरामीटर होता है, जो 3 प्रकार का हो सकता है: SOURCE, CLASS और RUNTIME, इसलिए लोम्बोक में RetentionPolicy.SOURCE है, डिफ़ॉल्ट रूप से, जिसका अर्थ है कि यह एनोटेशन रनटाइम में दिखाई नहीं देता है और आप इसे प्रतिबिंब के माध्यम से नहीं पाएंगे।

हमारी परियोजना में, सार्वजनिक तरीकों के सभी मापदंडों को एनोटेट किया जाता है (आदिमों की गिनती नहीं), अगर यह समझा जाता है कि पैरामीटर शून्य नहीं हो सकता है, यदि विपरीत माना जाता है, तो पैरामीटर वसंत @ एनुल्बल द्वारा एनोटेट किया जाता है। आप इसमें शामिल हो सकते हैं, हम सभी सार्वजनिक तरीकों की तलाश करेंगे, और उनमें सभी पैरामीटर जो @Nullable के साथ चिह्नित नहीं हैं और आदिम नहीं हैं।
हमारा मतलब है कि अन्य सभी मामलों के लिए, एनोटेशन @NonNull मापदंडों पर होना चाहिए।

सुविधा के लिए, जब भी संभव हो, हम निजी तरीकों से तर्क फैलाएंगे, एक शुरुआत के लिए हमें सभी सार्वजनिक तरीके मिलेंगे:

 private List<Method> getPublicMethods(final Class clazz) { return Arrays.stream(clazz.getDeclaredMethods()) .filter(METHOD_FILTER) .collect(toList()); } 

जहां METHOD_FILTER एक नियमित विधेय है जिसमें हम कहते हैं कि:

• विधि सार्वजनिक होनी चाहिए
• यह सिंटैटिक नहीं होना चाहिए (और ऐसा तब होता है जब आपके पास एक कच्चा पैरामीटर होता है)
• यह अमूर्त नहीं होना चाहिए (अलग-अलग और नीचे के अमूर्त वर्ग के बारे में)
• विधि का नाम बराबर नहीं होना चाहिए (यदि किसी प्रकार का दुष्ट व्यक्ति हमारे POJO ढांचे के इनपुट पर एक वर्ग को बराबरी के साथ तय करता है)

हमें अपनी जरूरत के सभी तरीके मिल जाने के बाद, हम उन्हें एक लूप में छांटना शुरू करते हैं,
यदि विधि में कोई पैरामीटर नहीं है, तो यह हमारा उम्मीदवार नहीं है:

 if (method.getParameterCount() == 0) { continue; } 

यदि पैरामीटर हैं, तो हमें यह समझने की आवश्यकता है कि क्या वे @ नोटोन्यूलेटेड हैं (और अधिक सटीक रूप से, क्या उनके अनुसार होना चाहिए,


ऐसा करने के लिए, एक नक्शा बनाएं और विधि में अनुक्रम के अनुसार हमारे मापदंडों को उसमें डाल दें, और उनके विपरीत हम एक झंडा लगाते हैं जो कहता है कि क्या टिप्पणी @NonNull ऊपर होनी चाहिए या नहीं:

 int nonNullAnnotationCount = 0; int index = 0; val parameterCurrentMethodArray = method.getParameters(); val notNullAnnotationParameterMap = new HashMap<Integer, Boolean>(); for (val parameter : parameterCurrentMethodArray) { if (isNull(parameter.getAnnotation(Nullable.class)) && isFalse(parameter.getType().isPrimitive())) { notNullAnnotationParameterMap.put(index++, true); nonNullAnnotationCount++; } else { notNullAnnotationParameterMap.put(index++, false); } } if (nonNullAnnotationCount == 0) { continue; } 

यह नक्शा हमारे लिए उपयोगी है, फिर विधि को कॉल करें और इसे एनोटेशन @ नोनल के साथ सभी मापदंडों को बारी-बारी से पास करें, और केवल पहले एक को नहीं।

NonNullAnnotationCount पैरामीटर मायने रखता है कि विधि में कितने मापदंडों को @NonNull एनोटेट किया जाना चाहिए, यह प्रत्येक विधि के लिए कॉल एकीकरण इंटरैक्शन की संख्या निर्धारित करेगा।

वैसे, अगर कोई @ नोनल एनोटेशन नहीं हैं (पैरामीटर हैं, लेकिन सभी आदिम या @ नॉबल हैं), तो इसके बारे में बात करने के लिए कुछ भी नहीं है:

 if (nonNullAnnotationCount == 0) { continue; } 

हमारे पास मापदंडों का एक नक्शा है। हम जानते हैं कि किसी विधि को कॉल करने के लिए कितनी बार और किस स्थिति में अशक्त करना है, मामला छोटा है (जैसा कि मैंने भोलेपन से बिना समझे सोचा है), हमें कक्षा की एक आवृत्ति बनाने और उन पर कॉल करने के तरीकों की आवश्यकता है।

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

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

ठीक है, चलो इसे क्रम में करते हैं।

पहला मामला एक निजी निर्माता के साथ एक वर्ग है:

 if (ONLY_ONE_PRIVATE_CONSTRUCTOR_FILTER.test(clazz)) { notNullAnnotationParameterMap.put(currentNullableIndex, false); method.invoke(clazz, invokeMethodParameterArray); makeErrorMessage(method); } 

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

कोड में, यह इस तरह दिखता है:

 val invokeMethodParameterArray = new Object[parameterCurrentMethodArray.length]; boolean hasNullParameter = false; int currentNullableIndex = 0; for (int i = 0; i < invokeMethodParameterArray.length; i++) { if (notNullAnnotationParameterMap.get(i) && isFalse(hasNullParameter)) { currentNullableIndex = i; invokeMethodParameterArray[i] = null; hasNullParameter = true; } else { mappingParameter(parameterCurrentMethodArray[i], invokeMethodParameterArray, i); } } 

तात्कालिकता का पहला विकल्प हल किया गया था।

इसके अलावा इंटरफेस, एक इंटरफ़ेस का एक उदाहरण लेना और बनाना असंभव है (इसमें कंस्ट्रक्टर भी नहीं है)।

इसलिए, इंटरफ़ेस के साथ यह इस तरह होगा:

 if (INTERFACE_FILTER.test(clazz)) { notNullAnnotationParameterMap.put(currentNullableIndex, false); method.invoke(createInstanceByDynamicProxy(clazz, invokeMethodParameterArray), invokeMethodParameterArray); makeErrorMessage(method); } 

createInstanceByDynamicProxy हमें एक वर्ग पर एक उदाहरण बनाने की अनुमति देता है यदि यह कम से कम एक इंटरफ़ेस लागू करता है, या स्वयं एक इंटरफ़ेस है


लेकिन अंदर ऐसा है:

 private Object createInstanceByDynamicProxy(final Class clazz, final Object[] invokeMethodParameterArray) { return newProxyInstance( currentThread().getContextClassLoader(), new Class[]{clazz}, (proxy, method1, args) -> { Constructor<Lookup> constructor = Lookup.class .getDeclaredConstructor(Class.class); constructor.setAccessible(true); constructor.newInstance(clazz) .in(clazz) .unreflectSpecial(method1, clazz) .bindTo(proxy) .invokeWithArguments(invokeMethodParameterArray); return null; } ); } 

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

अमूर्त वर्ग को तत्काल करने का विकल्प यह होगा:

 if (isAbstract(clazz.getModifiers())) { createInstanceByCGLIB(clazz, method, invokeMethodParameterArray); makeErrorMessage(); } 

makeErrorMessage (), जो पहले से ही कोड उदाहरणों में देखा गया था, परीक्षण को छोड़ देता है, अगर हमने एनोटेट @ एनऑनलाइन पैरामीटर के साथ विधि को अशक्त कहा जाता है और यह नहीं गिरता है, तो परीक्षण काम नहीं करता है, आपको ड्रॉप करना होगा।

पैरामीटर मैपिंग के लिए, हमारे पास एक सामान्य तरीका है जो कंस्ट्रक्टर और विधि दोनों मापदंडों को मैप और लॉक कर सकता है, यह इस तरह दिखता है:

 private void mappingParameter(final Parameter parameter, final Object[] methodParam, final int index) throws InstantiationException, IllegalAccessException { if (isFinal(parameter.getType().getModifiers())) { if (parameter.getType().isEnum()) { methodParam[index] = Enum.valueOf( (Class<Enum>) (parameter.getType()), parameter.getType().getEnumConstants()[0].toString() ); } else if (parameter.getType().isPrimitive()) { mappingPrimitiveName(parameter, methodParam, index); } else if (parameter.getType().getTypeName().equals("byte[]")) { methodParam[index] = new byte[0]; } else { methodParam[index] = parameter.getType().newInstance(); } } else { methodParam[index] = mock(parameter.getType()); } } 

Enum (केक पर चेरी) के निर्माण पर ध्यान दें, सामान्य तौर पर, आप Enum को केवल ले और बना नहीं सकते।

यहाँ अंतिम मापदंडों के लिए अपने स्वयं के मानचित्रण, गैर-अंतिम के लिए अपने स्वयं के, और फिर बस पाठ (कोड) में।

खैर, हमने कंस्ट्रक्टर के लिए और विधि के लिए पैरामीटर बनाने के बाद, हम अपना उदाहरण बनाते हैं:

 val firstFindConstructor = clazz.getConstructors()[0]; val constructorParameterArray = new Object[firstFindConstructor.getParameters().length]; for (int i = 0; i < constructorParameterArray.length; i++) { mappingParameter(firstFindConstructor.getParameters()[i], constructorParameterArray, i); } notNullAnnotationParameterMap.put(currentNullableIndex, false); createAndInvoke(clazz, method, invokeMethodParameterArray, firstFindConstructor, constructorParameterArray); makeErrorMessage(method); 

हम पहले से ही यह सुनिश्चित कर चुके हैं कि चूंकि हम कोड के इस चरण में पहुंच चुके हैं, इसका मतलब है कि हमारे पास कम से कम एक निर्माता है, हम उदाहरण बनाने के लिए कोई भी ले सकते हैं, इसलिए हम पहले एक को लेते हैं जो हम देखते हैं, देखें कि क्या यह पैरामीटर में पैरामीटर है और यदि नहीं, तो कॉल करें इस तरह:

 method.invoke(spy(clazz.getConstructors()[0].newInstance()), invokeMethodParameterArray); 

खैर, अगर ऐसा कुछ है:

 method.invoke(spy(clazz.getConstructors()[0].newInstance()), invokeMethodParameterArray); 

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

निष्कर्ष

यह कोड एक वास्तविक परियोजना में एनोटेशन का काम करता है और परीक्षण करता है, फिलहाल एक ही विकल्प संभव है, जब सब कुछ कहा जा सकता है।

कक्षा में एक लोम्बॉक सेटर की घोषणा करें (यदि कोई विशेषज्ञ है जो सेज़ो क्लास में सेटर सेट नहीं करता है, हालांकि ऐसा नहीं होता है) और जिस क्षेत्र पर सेटर घोषित किया जाएगा वह अंतिम नहीं होगा।

फिर फ्रेमवर्क कृपया यह कहेगा कि एक सार्वजनिक तरीका है, और इसका एक पैरामीटर है, जिस पर कोई @NonNull एनोटेशन नहीं है, समाधान सरल है: लॉटर के संदर्भ में अपने पैरामीटर को स्पष्ट रूप से घोषित करें और एनोटनल / @ Nullable के संदर्भ में अपने पैरामीटर को एनोटेट करें।

कृपया ध्यान दें कि यदि आप चाहते हैं कि मैं आपके परीक्षणों (या कुछ और) में विधि पैरामीटर के नाम से बंधा रहूं, तो डिफ़ॉल्ट रूप से, विधियों में चर नाम उपलब्ध नहीं हैं, आप arg [0] और arg [1], आदि पाएंगे। ।
रनटाइम में विधि नामों के प्रदर्शन को सक्षम करने के लिए, मावेन प्लगइन का उपयोग करें:

 <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>${maven.compiler.plugin.version}</version> <configuration> <source>${compile.target.source}</source/> <target>${compile.target.source}</target> <encoding>${project.build.sourceEncoding}</encoding> <compilerArgs><arg>-parameters</arg></compilerArgs> </configuration> </plugin> 

और विशेष रूप से इस कुंजी:

 <compilerArgs><arg>-parameters</arg></compilerArgs> 

मुझे आशा है कि आप रुचि रखते थे।