Junit4: BiMatcher पदानुक्रम का परिचय देता है

को निर्मित 8 फ़र॰ 2018 · 9टिप्पणियाँ · स्रोत: junit-team/junit4

एक अच्छी सुविधा BiMatcher पदानुक्रम ( org.hamcrest.Matcher का एनालॉग, लेकिन 2 तर्कों का उपभोग) पेश करना होगा। वैकल्पिक रूप से इस उद्देश्य के लिए मानक Comparator का उपयोग किया जा सकता है। इसके अलावा BiPredicate का उपयोग किया जा सकता है (यह JUnit को Java-8 से जोड़ देगा, लेकिन आउट-ऑफ-द-बॉक्स AND/OR/NOT लॉजिक जोड़ देगा)।
आगे के सभी कोड के लिए कुछ नोट्स:

BiMatcher , BiPredicate और Comparator नामों का परस्पर उपयोग किया जाएगा।
सभी कोड अंतिम नहीं हैं और केवल एक सामान्य विचार है।

Assert वर्ग में जोड़ने की मुख्य विधियाँ:

assertThat(T expected, T actual, Comparator<T> biMatcher);
assertThat(String message, T expected, T actual, Comparator<T> biMatcher); (शायद जरूरी नहीं, नीचे देखें)।
एकाधिक assertArray() विधियां (नीचे देखें)।

प्रेरणा: कभी-कभी आपको वस्तुओं के बैच के खिलाफ बहुत सी समान जांच करने की आवश्यकता होती है। मौजूदा कार्यक्षमता इसकी अनुमति देती है, लेकिन बहुत सारे अतिरिक्त कोड (लूप और शर्तों) के साथ। Comparator इसे कम कोड और उच्च लचीलेपन के साथ किया जा सकता है।

वास्तविक उदाहरण (जिससे मैंने वास्तव में इस सुविधा के बारे में सोचना शुरू किया): सरणी में सभी वस्तुओं का परीक्षण करने की आवश्यकता समान है या समान नहीं है (बूलियन ध्वज के आधार पर)।

वर्तमान जुनीट क्षमताओं के साथ ऐसा दिखेगा:
छोटा:

for (int i = 0; i < elements.length - 1; i++) {
  if (checkSame) { // Same
    assertSame("elements must be the same.", elements[i], elements[i + 1]);
  } else { // Not same
    assertNotSame("elements must be not the same.", elements[i], elements[i + 1]);
  }
}

बेहतर प्रदर्शन (लेकिन परीक्षणों में प्रदर्शन की परवाह कौन करता है):

if (checkSame) { // Same
  for (int i = 0; i < elements.length - 1; i++) {
    assertSame("elements must be the same.", elements[i], elements[i + 1]);
  }
else { // Not same
  for (int i = 0; i < elements.length - 1; i++) {
    assertNotSame("elements must be not the same.", elements[i], elements[i + 1]);
  }
}

इसके अलावा हम अपने Comparator को लागू कर सकते हैं और assertTrue()/assertFalse() , लेकिन तुलनित्र बनाने के लिए कोड भी बड़ा होगा (जब तक कि हम लैम्ब्डा का उपयोग नहीं करते)।

नए दृष्टिकोण के साथ कोड मेरे लिए बहुत छोटा और साफ दिखाई देगा, जैसे:

Comparator<T> comparator = checkSame ? BiMatchers.same() : BiMatchers.notSame();
String message = checkSame ? "elements must be the same." : "elements must be not the same.";
for (int i = 0; i < elements.length - 1; i++) {
  assertThat(message, elements[i], elements[i + 1], comparator);
}

इसे और भी छोटा बनाने के लिए, हम वैकल्पिक message संपत्ति के साथ Comparator से MessagedComparator तक बढ़ा सकते हैं, इसलिए जुनीट इसे किसी भी तरह से वहां से ले जाएगा। इस कदर:

MessagedComparator<T> comparator = checkSame ? BiMatchers.same("elements must be the same.") : BiMatchers.notSame("elements must be not the same.");
for (int i = 0; i < elements.length - 1; i++) {
  assertThat(message, elements[i], elements[i + 1], comparator);
}

परिणाम बहुत दूरगामी हैं:
1) Assert वर्ग सामान्य रूप से बहुत लचीला होगा, क्योंकि आप बिना किसी कोड के किसी भी मानक या स्वयं के तुलनित्र का उपयोग कर सकते हैं।
2) पिछले के परिणामस्वरूप, किसी भी स्थिति को इंजेक्ट करने के लिए लैम्ब्डा का अधिक आसानी से उपयोग किया जा सकता है।
3) अतिरिक्त लॉजिक कैस्केडिंग (AND, OR, NOT) को आउट-ऑफ़-द-बॉक्स जोड़ा जा सकता है ( org.hamcrest.CoreMatchers जैसा कुछ)। वर्तमान में किसी भी नई मिनी-फीचर के लिए एक नई विधि की आवश्यकता है, उदाहरण के लिए assertNotSame() आगे assertSame() आदि। या फिर हमें assertTrue()/assertFalse() विधियों की आवश्यकता है।
4) पूरे Assert वर्ग को एकीकृत रूप में पुन: सक्रिय किया जा सकता है। सिर्फ एक उदाहरण:

public static void assertSame(String message, Object expected, Object actual) {
  assertThat(message, expected, actual, BiMatchers.same())
}

public static void assertThat(String message, T expected, T actual, Comparator<T> biMatcher) {
...
}

या जैसा कि पहले ही उल्लेख किया गया है:

public static void assertSame(String message, Object expected, Object actual) {
  assertThat(expected, actual, BiMatchers.same(message))
}

public static void assertThat(T expected, T actual, MessagedComparator<T> biMatcher) {
...
}

5) assertArray() विधियों को जोड़ा जा सकता है (इस प्रकार पुराने तरीकों को फिर से तैयार किया गया)। जैसे:

public static void assertArrayEquals(boolean[] expecteds, boolean[] actuals) {
  assertArray(expecteds, actuals, BiMatchers.equals());
}

public static void assertArray(boolean[] expecteds, boolean[] actuals, Comparator<Boolean>) {
...
}

तो उदाहरण के लिए आप 2 सरणियों में सभी तत्वों की जांच कर सकते हैं जितना आसान है:

Assert.assertArray(array1, array2, BiMatchers.same());

साथ ही सरणी-लंबाई या अन्य जांचों को अलग से नियंत्रित किया जा सकता है। छद्म कोड:

Assert.assertArray(array1, array2, and(sameLength(), same()));

स्रोत

gitIvanB

सभी 9 टिप्पणियाँ

इस मुद्दे को उठाने के लिए धन्यवाद।

मैं पसंद करूंगा कि जुनीट 4.x अधिक दावा डीएसएल न जोड़ें। डीएसएल को सही और लचीला बनाना वाकई मुश्किल है, और मुझे यकीन नहीं है कि जुनीट में उस पर समय और प्रयास खर्च करना समझ में आता है जब सत्य या उत्सव जैसे अच्छे तीसरे पक्ष के दावे ढांचे होते हैं।

kcooney 8 फ़र॰ 2018

👍1

साथ ही, जावा 8 की आवश्यकता वाली सुविधाओं को http://github.com/junit-team/junit5 पर जाना चाहिए

kcooney 8 फ़र॰ 2018

@gitIvanB इस मुद्दे को खोलने के लिए धन्यवाद। @kcooney की तरह, मुझे भी लगता है कि यह एक अभिकथन पुस्तकालय, जैसे AssertJ द्वारा सबसे अच्छा संबोधित किया जाएगा।

marcphilipp 8 फ़र॰ 2018

👍1

@kcooney , @marcphilipp , इशारा करने के लिए धन्यवाद। ऐसा लगता है कि दावा libs का उपयोग यहां सबसे अच्छा अभ्यास है।
एक अतिरिक्त प्रश्न। क्या मैं अंगूठे के नियम के रूप में उपयोग कर सकता हूं कि Assert को बहिष्कृत कर दिया गया है (या सलाह नहीं दी गई है)? विशेष रूप से भविष्य में JUnit-4 से JUnit-5 में संभावित अपग्रेड को ध्यान में रखते हुए।

gitIvanB 9 फ़र॰ 2018

@gitIvanB प्रश्न थोड़ा स्पष्ट नहीं है। यदि जूनिट 4 के खिलाफ विकास करना org.junit.Assert का उपयोग करता है, तो जूनिट 5 के खिलाफ विकसित होने पर org.junit.jupiter.api.Assertions

प्रत्येक पंक्ति पर Assert. होने से बचने के लिए अनुशंसित दृष्टिकोण स्थिर रूप से विधियों को आयात कर रहा है।

panchenko 9 फ़र॰ 2018

@gitIvanB आपको निश्चित रूप से junit.framework.Assert उपयोग नहीं करना चाहिए, लेकिन org.junit.Assert ठीक है। जब आप अपग्रेड करते हैं, तो आप जुनीट 4 को जुनीट ज्यूपिटर अभिकथन में बदलने के लिए आईडीई का उपयोग कर सकते हैं (आईडीईए पहले से ही इसका समर्थन करता है)। सबसे बड़ा अंतर यह है कि वैकल्पिक संदेश पैरामीटर पहले जुनीट 4 में आता है लेकिन बृहस्पति में अंतिम होता है। वैकल्पिक रूप से, आप अब एक अलग अभिकथन पुस्तकालय का उपयोग करने का निर्णय ले सकते हैं और विंटेज से जुपिटर की ओर पलायन करते समय उसका उपयोग करना जारी रख सकते हैं।

marcphilipp 9 फ़र॰ 2018

@panchenko , @marcphilipp तो जैसा कि मैंने समझा कि org.junit.Assert सील कर दिया गया है और नए तरीकों से समृद्ध नहीं होगा। जुनीट -5 में मुझे या तो org.junit.jupiter.api.Assertions ( org.junit.Assert प्रतिस्थापन के रूप में) या कुछ दावा lib का उपयोग करने की आवश्यकता है।
मुझे जुनीट -5 सीखने के लिए कुछ समय चाहिए, लेकिन पहली नज़र से org.junit.jupiter.api.Assertions ऐसा लगता है कि सामान्य रूप से इसका दृष्टिकोण org.junit.Assert । तो यह एक बड़ा मौका है कि मुझे जुनीट -5 के लिए समान टिकट बनाने की ज़रूरत है :) मेरा मानना है कि जुनीट -5 को या तो पूरी तरह से दावा करना चाहिए या पूरी तरह से दावा libs को सौंपना चाहिए।

gitIvanB 9 फ़र॰ 2018

@gitIvanB JUnit का दर्शन जावा में जावा के लिए परीक्षण लिखने के लिए एक अच्छा, एक्स्टेंसिबल फ्रेमवर्क प्रदान करना है। एक एक्स्टेंसिबल फ्रेमवर्क होने के नाते, हम अक्सर देखते हैं कि अन्य ओपन सोर्स प्रोजेक्ट्स फ्रेमवर्क का विस्तार करते हैं और/या रिच टेस्टिंग लाइब्रेरी प्रदान करते हैं जिनका उपयोग JUnit के साथ किया जा सकता है।

अभिकथन के लिए, ऐसी कई परियोजनाएँ हैं जो अभिकथन का एक समृद्ध समूह प्रदान करती हैं, कभी-कभी इस तरह से जो एक्स्टेंसिबल हो।
उदाहरण के लिए, Google ट्रुथ (https://github.com/google/truth), FEST (https://github.com/alexruiz/fest-assert-2.x), AssertJ (http://joel-) है। costigliola.github.io/assertj/) और हैमक्रेस्ट (http://hamcrest.org/JavaHamcrest/)।

क्योंकि वहाँ बहुत सारे अद्भुत अभिकथन पुस्तकालय हैं, मैं org.junit.Assert लिए नए फीचर अनुरोधों को स्वीकार करने में अनिच्छुक रहा हूँ। मैं इसे जमे हुए नहीं मानूंगा (हालांकि मैं junit.framework.Assert जमे हुए पर विचार करूंगा)। वास्तव में, 4.13 assertThrows पेश करेगा। लेकिन चूंकि हमारे पास उन परियोजनाओं के रूप में समृद्ध दावों का एक समूह कभी नहीं होगा, इसलिए हम मूल बातें प्रदान करने में सहज महसूस करते हैं।

दूसरे तरीके से कहें तो, उन परियोजनाओं के उपयोग और रखरखाव के आसपास हीथरी समुदायों का गठन हुआ है, इसलिए मुझे लगता है कि हमें उन्हें गले लगाना चाहिए और उनका समर्थन करना चाहिए।

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

मैं यह तय करने के लिए JUnit5 टीम पर छोड़ता हूं कि वे किस प्रकार के परिवर्तनों पर विचार करेंगे। यदि आप दृढ़ता से महसूस करते हैं कि
आपके द्वारा प्रस्तावित तरीके महत्वपूर्ण हैं क्योंकि अच्छे परीक्षण लिखने की नींव वहां एक मुद्दा बनाने के लिए स्वतंत्र महसूस होती है।

kcooney 9 फ़र॰ 2018

👍1

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

या, जैसा कि जुनीट 5 उपयोगकर्ता मार्गदर्शिका इसे रखती है:

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

तो, यह या तो जमे हुए नहीं है, लेकिन लक्ष्य जुनीट 4 के समान है, अर्थात् उपयोगकर्ताओं को शुरू करने के लिए दावे का मूल सेट प्रदान करना। हम अपने स्वयं के यूनिट परीक्षणों के लिए भी AssertJ का उपयोग करते हैं।

marcphilipp 9 फ़र॰ 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

Junit4: BiMatcher पदानुक्रम का परिचय देता है

सभी 9 टिप्पणियाँ

संबंधित मुद्दों