Details
-
Bug
-
Status: Resolved
-
Minor
-
Resolution: Fixed
-
None
-
None
Description
Apparently we have included multiple versions of JUnit and/or Hamcrest, and the new versions are not first on the class path.
This means that when an assertThat call tries to report that an actual value mismatches an expected value, it dies with a NoSuchMethod error.
That in turn means that what would have been an informative test-failure message turns into a confusing crash.
It seems that something like this is happening: The unit test is calling the new version of some JUnit or Hamcrest class. That class is calling a method in another class (in Hamcrest), but the old version of the class gets loaded, so the call fails with NoSuchMethodError.
Here's a sample stacktrace:
java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:18)
at org.apache.drill.jdbc.test.DatabaseMetaDataTest.test_getColumns_resultSetMetadataIsCorrect(DatabaseMetaDataTest.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:606)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)