IntelliJ 10.5 में टेस्ट रन करते समय "NoSuchMethodError: org.hamcrest.Matcher.describeMismatch" प्राप्त करना

Question

मैं JUnit-dep 4.10 और Hamcrest 1.3.RC2 का उपयोग कर रहा हूं।

मैंने एक कस्टम मिलानकर्ता बनाया है जो निम्नलिखित की तरह दिखता है:

public static class MyMatcher extends TypeSafeMatcher<String> {
    @Override
    protected boolean matchesSafely(String s) {
        /* implementation */
    }

    @Override
    public void describeTo(Description description) {
        /* implementation */
    }

    @Override
    protected void describeMismatchSafely(String item, Description mismatchDescription) {

        /* implementation */
    }
}

चींटी का उपयोग करके कमांड लाइन से चलाने पर यह पूरी तरह से ठीक काम करता है। लेकिन जब IntelliJ से चलाया जाता है, तो यह विफल रहता है:

java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
    at com.netflix.build.MyTest.testmyStuff(MyTest.java:40)

मेरा अनुमान है कि यह गलत हैमस्ट्रैस्ट का उपयोग कर रहा है। मुझे यह कैसे पता चलेगा कि कौन सी हैमक्रेस्ट.चैटरएस्सर इसका उपयोग कर रही है (यानी हैमरेस्ट.चैचर्स डिटेल्स के लिए इसका उपयोग किस जार फाइल के लिए है)? AFAICT, मेरी कक्षापथ में एकमात्र हैमरेस्ट जार 1.3.RC2 है।

क्या IntelliJ IDEA ने JUnit या Hamcrest की अपनी कॉपी का उपयोग किया है?

मैं रनटाइम क्‍लसपाथ का उत्‍पादन कैसे करूं जिसका इंटेलीजेंस उपयोग कर रहा है?

Answer 1

सुनिश्चित करें कि हैमरेस्ट जार आपके JUnit जार की तुलना में आयात के आदेश पर अधिक है ।

JUnit अपने स्वयं के org.hamcrest.Matcherवर्ग के साथ आता है जिसका उपयोग संभवतः इसके बजाय किया जा रहा है।

आप कनिष्ठ-वर्ग 4.10.jar को डाउनलोड और उपयोग कर सकते हैं जो कि हैमरेस्ट कक्षाओं के बिना JUnit है।

मॉकिटो में हैमरेस्ट वर्ग भी है, इसलिए आपको इसे भी स्थानांतरित करने की आवश्यकता हो सकती है

Comments

ओपी ने कहा कि वे पहले से ही '-डेप-' जार का उपयोग कर रहे थे। लेकिन आपका अनुमान है कि यह ज्यूनिट जार से मैचर वर्ग का उपयोग कर रहा है। तो यह शायद है कि आईडीई JUnit की अपनी प्रति का उपयोग कर रहा है।

— MatrixFrog

मैंने IntelliJ की कॉपी junit.jar और junit-4.8.jar की हटा दी, IntelliJ के lib / निर्देशिका में junit-dep-4.10.jar स्थापित किया, और समस्या अभी भी होती है।

— नोएल याप

JUnit 4.11 Hamcrest 1.3 के साथ संगत है और JUnit 4.10 Hamcrest 1.1 के साथ संगत है search.maven.org/remotecontent?filepath=junit/junit-dep/4.10/...

— मुथु

सुनिश्चित करें कि आप मॉकिटो-सभी का उपयोग नहीं कर रहे हैं, लेकिन इसके बजाय हैमरेस्ट के बहिष्करण के साथ मॉकिटो-कोर

— उल्फ

यह कार्यालय में 7:33 PM है मैं एक महत्वपूर्ण विशेषता पर काम कर रहा हूं जिसे मुझे छुट्टी में जाने से पहले वितरित करना होगा और यह शुक्रवार है, मैं अगले सप्ताह उस अवकाश में हूं !!!!!! मैं इस त्रुटि को कैसे प्राप्त कर सकता हूं!

— एडेलिन

Answer 2

यह समस्या तब भी उत्पन्न होती है जब आपके पास मॉकिटो-सभी आपके क्लास पथ पर होता है, जो पहले से ही पदावनत है।

यदि संभव हो तो सिर्फ मॉकिटो-कोर शामिल करें ।

जूनट, मॉकिटो और हैमरेस्ट को मिलाने के लिए मावेन कॉन्फिगर:

<dependencies>
  <dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-core</artifactId>
    <version>1.3</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-library</artifactId>
    <version>1.3</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.5</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
  </dependency>
</dependencies>

Comments

मॉकिटो के नए संस्करणों के रूप में काफी है पॉरमॉक के साथ हैमरेस्ट भी शामिल हैं!

— टॉम पार्किंसंस

क्या मॉकिटो के बजाय मॉकिटो-कोर होना चाहिए?

— user944849

आप बस कोर को शामिल कर सकते हैं यदि आपको केवल सभी की गति में इसकी आवश्यकता है लेकिन उपरोक्त सभी मामलों में काम करना चाहिए। आश्रितों का क्रम प्राथमिकता के क्रम में ऊपर से शुरू होने वाला महत्वपूर्ण बिट मवन 3 है।

— टॉम पार्किंसंस

आपको मॉकिटो-सभी को शामिल नहीं करना चाहिए क्योंकि इसमें हैमरेस्ट 1.1 शामिल हैं, इसके बजाय मॉकिटो-कोर शामिल करें और इसमें से हैन्क्रेस्ट शामिल करें (जो आप सभी से नहीं कर सकते हैं)

— उलफ लिंडबैक

"यदि संभव हो तो सिर्फ मॉकिटो-कोर शामिल करें।" ठीक है, तो फिर यह उत्तर अभी भी मॉकिटो-ऑल का उपयोग क्यों करता है?

— चुपके रब्बी

Answer 3

समस्या यह थी कि गलत hamcrest.Matcher, नहीं hamcrest.MatcherAssert, वर्ग का उपयोग किया जा रहा था। यह एक कनिष्ठ-4.8 निर्भरता से खींचा जा रहा था, मेरी निर्भरता में से एक निर्दिष्ट कर रहा था।

परीक्षण करते समय, किस स्रोत से निर्भरता (और संस्करण) शामिल हैं, यह देखने के लिए:

mvn dependency:tree -Dscope=test

Comments

मेरी भी यही समस्या थी। मैं JUnit-dep और Hamcrest-core का उपयोग कर रहा था, लेकिन मेरे पास पहले pomermock था जो pom में सूचीबद्ध था, जिसके परिणामस्वरूप JUnit को JUnit-dep और Hamcrest से पहले शामिल किया गया था।

— जॉन बी

मॉकिटो-सभी में कुछ हैमरेस्ट क्लास भी शामिल हैं। मॉकिटो-कोर का उपयोग करना और हैमरेस्ट निर्भरता को बाहर करना बेहतर है।

— ब्रम्बो

बस एक ही समस्या पर ठोकर खाई। समाधान जूनियर संस्करण को 4.11 में बदल रहा था जो संगत है (यानी "से कक्षाएं शामिल हैं") हैमरेस्ट 1.3 के साथ

— r3mbol

उन जहां सभी सुझावों के रूप में अच्छी तरह से काम नहीं किया के लिए (निर्भरता आदेश, बहिष्करण, की जगह को दूर करने -allके साथ -core, आदि ...): मैं संस्करण 1.1 के लिए hamcrest वापस बदलना पड़ा और अब सब कुछ फिर से काम करता है।

— फेलिक्स हैप्पीस्पेल

मेरे लिए यह काम किया जब मैं करने के लिए अपने आयात बदल import static org.mockito.Matchers.anyString;सेimport static org.mockito.ArgumentMatchers.anyString;

— श्रीकांत प्रभु

Answer 4

निम्नलिखित आज सबसे सही होना चाहिए। ध्यान दें, कनिष्ठ 4.11 हैमरेस्ट-कोर पर निर्भर करता है, इसलिए आपको यह निर्दिष्ट करने की आवश्यकता नहीं होनी चाहिए कि मॉकिटो-सभी का उपयोग नहीं किया जा सकता है क्योंकि इसमें शामिल है (नहीं निर्भर करता है) हैमरेस्ट 1.1

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-core</artifactId>
    <version>1.10.8</version>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

Comments

ध्यान दें कि JUnit 4.12 अब हैमरेस्ट-कोर 1.3 पर निर्भर करता है।

— JeeBee

mockito-allमेरी मदद करने से बहिष्करण , नहीं mockito-core। pom.xmlकार्यों में मॉकिटो से पहले हैमरेस्ट की घोषणा करना ।

— किरिल

Answer 5

थोड़ा संघर्ष करने के बाद मेरे लिए यह काम किया

<dependency>
    <groupId>org.hamcrest</groupId>
    <artifactId>hamcrest-all</artifactId>
    <version>1.3</version>
    <scope>test</scope>
 </dependency>

 <dependency>
    <groupId>org.mockito</groupId>
    <artifactId>mockito-all</artifactId>
    <version>1.9.5</version>
    <scope>test</scope>
 </dependency>

 <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.11</version>
    <scope>test</scope>
 </dependency>

Comments

मेरे लिए भी वैसा ही। इस क्रम में निर्भरता डालने से मावेन को ट्रांसिटिव डिप्स को सही ढंग से हल करने में मदद मिलती है। स्पष्ट रूप से मॉकिटो-कोर या मॉकिटो से हैमरेस्ट को छोड़कर-सभी सुरक्षित हो सकते हैं, अगर कोई आपके पोम में डिप्रेस करता है।

— Mat

Answer 6

प्रयत्न

expect(new ThrowableMessageMatcher(new StringContains(message)))

के बजाय

expectMessage(message)

आप ExpectedExceptionकोड को लपेटने के लिए एक कस्टम या उपयोगिता विधि लिख सकते हैं ।

Answer 7

मुझे पता है कि यह एक पुराना धागा है लेकिन मेरे लिए इस मुद्दे को हल करने से मेरी बिल्ड.ग्रेडल फ़ाइलों में निम्नलिखित शामिल हो गए। जैसा कि पहले ही कहा जा चुका है कि अनुकूलता मुद्दा हैmockito-all

संभवतः उपयोगी पोस्ट :

testCompile ('junit:junit:4.12') {
    exclude group: 'org.hamcrest'
}
testCompile ('org.mockito:mockito-core:1.10.19') {
    exclude group: 'org.hamcrest'
}
testCompile 'org.hamcrest:hamcrest-core:1.3'

Answer 8

इस तथ्य के बावजूद कि यह एक बहुत पुराना सवाल है और संभवत: पहले के कई विचारों ने कई समस्याओं को हल किया है, मैं अभी भी उस समुदाय के साथ समाधान साझा करना चाहता हूं जिसने मेरी समस्या को ठीक किया।

मैंने पाया कि समस्या "hasItem" नामक एक फ़ंक्शन थी, जिसका उपयोग मैं यह जांचने के लिए कर रहा था कि क्या JSON-Array में कोई विशिष्ट आइटम है या नहीं। मेरे मामले में मैंने टाइप लॉन्ग के मान की जाँच की।

और इस समस्या के लिए नेतृत्व किया।

किसी तरह, मिलानकर्ताओं को टाइप लॉन्ग के मानों की समस्या है। (मैं JUnit या Rest-Assured का उपयोग इतनी अधिक idk नहीं करता। ठीक क्यों, लेकिन मुझे लगता है कि लौटे JSON- डेटा में केवल इंटेगर शामिल हैं।)

तो समस्या को ठीक करने के लिए मैंने जो किया वह निम्नलिखित था। के बजाय का उपयोग करने का:

long ID = ...;

...
.then().assertThat()
  .body("myArray", hasItem(ID));

आपको सिर्फ इंटेगर को कास्ट करना है। तो काम कोड इस तरह देखा:

long ID = ...;

...
.then().assertThat()
  .body("myArray", hasItem((int) ID));

यह शायद सबसे अच्छा समाधान नहीं है, लेकिन मैं सिर्फ यह उल्लेख करना चाहता था कि गलत / अज्ञात डेटा प्रकारों के कारण अपवाद भी फेंका जा सकता है।

Answer 9

मेरे लिए जो काम किया गया वह जूनियर टेस्ट कंपाइल से हैमरेस्ट ग्रुप को छोड़कर था।

यहाँ मेरे build.gradle से कोड है:

testCompile ('junit:junit:4.11') {
    exclude group: 'org.hamcrest'
}

यदि आप IntelliJ चला रहे हैं, तो आपको gradle cleanIdea idea clean buildफिर से निर्भरता का पता लगाने के लिए दौड़ने की आवश्यकता हो सकती है ।

Answer 10

मुझे पता है कि यह सबसे अच्छा जवाब नहीं है, लेकिन अगर आप क्लासपैथ काम नहीं कर सकते हैं, तो यह एक प्लान बी समाधान है।

अपने टेस्ट क्लासपाथ में, मैंने वर्णनमेस्मैच विधि के लिए एक डिफ़ॉल्ट कार्यान्वयन के साथ निम्नलिखित इंटरफ़ेस जोड़ा।

package org.hamcrest;

/**
 * PATCH because there's something wrong with the classpath. Hamcrest should be higher than Mockito so that the BaseMatcher
 * implements the describeMismatch method, but it doesn't work for me. 
 */
public interface Matcher<T> extends SelfDescribing {

    boolean matches(Object item);

    default void describeMismatch(Object item, Description mismatchDescription) {
        mismatchDescription.appendDescriptionOf(this).appendValue(item);
    }

    @Deprecated
    void _dont_implement_Matcher___instead_extend_BaseMatcher_();
}

Answer 11

मेरे पास एक ढाल परियोजना है और जब मेरा build.gradle निर्भरता अनुभाग इस तरह दिखता है:

dependencies {
    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.8.1'

    testImplementation group: 'org.mockito', name: 'mockito-all', version: '1.10.19'
    testImplementation 'junit:junit:4.12'
//    testCompile group: 'org.mockito', name: 'mockito-core', version: '2.23.4'

    compileOnly 'org.projectlombok:lombok:1.18.4'
    apt 'org.projectlombok:lombok:1.18.4'
}

यह इस अपवाद की ओर जाता है:

java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V

    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)

इस समस्या को ठीक करने के लिए, मैंने "मॉकिटो-कोर" के साथ "मॉकिटो-ऑल" प्रतिस्थापित किया है।

dependencies {
    implementation group: 'org.apache.commons', name: 'commons-lang3', version: '3.8.1'

//    testImplementation group: 'org.mockito', name: 'mockito-all', version: '1.10.19'
    testImplementation 'junit:junit:4.12'
    testCompile group: 'org.mockito', name: 'mockito-core', version: '2.23.4'

    compileOnly 'org.projectlombok:lombok:1.18.4'
    apt 'org.projectlombok:lombok:1.18.4'
}

मॉकिटो-ऑल और मॉकिटो-कोर के बीच का विवरण यहां पाया जा सकता है: https://solidsoft.wordpress.com/2012/09/11/beyond-the-mockito-refcard-part-3-mockito-core-vs-mockito निर्माण सभी में mavengradle आधारित परियोजनाओं /

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

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

Answer 12

मेरे मामले में, मुझे जूनियर-विंटेज से एक पुरानी बाधा को बाहर करना पड़ा:

<dependency>
  <groupId>org.junit.vintage</groupId>
  <artifactId>junit-vintage-engine</artifactId>
  <scope>test</scope>
  <exclusions>
    <exclusion>
      <groupId>org.hamcrest</groupId>
      <artifactId>hamcrest-core</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest</artifactId>
  <version>2.1</version>
  <scope>test</scope>
</dependency>

Answer 13

इसने मेरे लिए काम किया। कुछ भी बाहर करने की आवश्यकता नहीं है। मैं सिर्फ mockito-coreइसके बजाय इस्तेमाल कियाmockito-all

testCompile 'junit:junit:4.12'
testCompile group: 'org.mockito', name: 'mockito-core', version: '3.0.0'
testCompile group: 'org.hamcrest', name: 'hamcrest-library', version: '2.1'