5

I get the following error when running this code: (ColorMatrix getarray() returns a float[])

74 public void testHueShift() {
75     ColorMatrix cm1 = new ColorMatrix();
76     ColorMatrix cm2 = hueShift(0f);
77     assertArrayEquals(cm1.getArray(), cm2.getArray(), 0f);
78 }

the error:

 ----- begin exception -----
 java.lang.NoClassDefFoundError: org.junit.Assert
    at com.Common.lib.test.ColorFilterFactoryTest.testHueShift(ColorFilterFactoryTest.java:77)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:511)
    at junit.framework.TestCase.runTest(TestCase.java:154)
    at junit.framework.TestCase.runBare(TestCase.java:127)
    at junit.framework.TestResult$1.protect(TestResult.java:106)
    at junit.framework.TestResult.runProtected(TestResult.java:124)
    at junit.framework.TestResult.run(TestResult.java:109)
    at junit.framework.TestCase.run(TestCase.java:118)
    at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)
    at android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)
    at android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:545)
    at android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1551)
 ----- end exception -----

But the project build path has it:

enter image description here

EDIT
This is the Test class classpath enter image description here

This is the class under test (It is a library project) enter image description here

ilomambo
  • 8,290
  • 12
  • 57
  • 106

1 Answers1

4

The stack trace contains the hint for the solution: It contains junit.framework.TestCase (so this class is on the classpath) but later, it can't find org.junit.Assert.

This looks as if you have JUnit 3.8 on the classpath when running the test but JUnit 4 when you compile them.

Find out how the unit test runner builds the classpath and fix it there.

Aaron Digulla
  • 321,842
  • 108
  • 597
  • 820
  • I actually created the JUnit test plain vanilla using the Wizard in Eclipse. I did not tinker with the Build Path. Why should the unit test runner behave different for me than for anyone else? Apart from that I have not the faintest Idea how to check what you said :-( – ilomambo Mar 06 '14 at 14:08
  • You did give me an idea, my test library has mixed tests some are Junit tests (JUnit4) and some are Android JUnit tests (JUnit3) so this might be the source of the problem. – ilomambo Mar 06 '14 at 14:14
  • I think I figured it out, as I said I have mixed tests, but JUnit4 library should be backwards compatible to JUnit3. But even so, if your test extends `TestCase` you cannot take advantage of the new methods introduced by JUnit4 (like `assertArrayEquals`) you have to stick to JUnit3 limitations. – ilomambo Mar 06 '14 at 14:27
  • 2
    If both JARs are on the classpath, then odd things can happen if the wrong one is first. You can use JUnit 4 code in JUnit 3 tests by using `Assert.assertArrayEquals()` If that doesn't work because it picks JUnit 3's `Assert`, create a helper class which wraps the methods that you want to use. – Aaron Digulla Mar 06 '14 at 15:04
  • Only JUnit4 is in the classpath, you can see it has its own junit.framework in the picture I attached, that's probably the backwards compatibility code. I used `import static org.junit.Assert.*;` thats why `assertArrayEquals` was known at compile time. Right now I am surfing the net to find out why at runtime it is not found even if its library is in the classpath. Meanwhile using full package path `org.junit.Assert.assertArrayEquals()` is working. – ilomambo Mar 06 '14 at 15:13
  • If the class isn't on the classpath, then using the FQ name doesn't make a difference - you will always get a an error. See http://stackoverflow.com/questions/34413/why-am-i-getting-a-noclassdeffounderror-in-java – Aaron Digulla Mar 06 '14 at 15:22
  • The class is on the classpath. Using `import static` seems to be a different mechanism than FQ package, because the former fails at runtime, the later works. – ilomambo Mar 07 '14 at 04:55
  • That's really strange. Care to create a simple demo project that demonstrates the problem? – Aaron Digulla Mar 07 '14 at 11:21
  • I'll see if find some time to do it soon. – ilomambo Mar 08 '14 at 15:51
  • More strangeness, after I reordered the classpath **in the target class** putting Android dependencies and Private libraries at the end, the `import static` suddenly started to work as expected. For me the hocus phocus is finished, I will come back to this issue when Eclipse/Java offer a verbose mode to their compiling steps that will allow a better understanding of what they're doing. – ilomambo Mar 09 '14 at 07:19
  • Can you post the list of imports? – Aaron Digulla Mar 10 '14 at 10:46
  • I put the imports at the end of the question. Originally had `import static org.junit.Assert.*` but after Ctrl-Shift-O Eclipse re-arranged the imports as they are now, still works. – ilomambo Mar 10 '14 at 14:12
  • That doesn't make sense; the order of imports should have no influence whatsoever. – Aaron Digulla Mar 10 '14 at 15:15
  • I dind't say that, reread my comment, I reordered the libraries in the classpath (Order and Export). Still doesn't make sense to me, but I have no way of tracking what is really happening. – ilomambo Mar 10 '14 at 16:36
  • Ah, you changed the order of JARs on the classpath, not the import statements. That makes more sense :-) Errors like the above can happen when you have more than one version of a class on the classpath. Moving JUnit 4 to the start of the classpath should help. That said, I'd still expect errors about missing methods instead of `NoClassDefFoundError`. It's a bit mysterious. Can you post your classpath? – Aaron Digulla Mar 10 '14 at 16:51
  • I put two more pics. If this is not what you meant, please tell specifically where to fetch the info you want. Thanks for your attention, I appreciate it. Keep in mind that for now I got my tests working and I am not stucked on this issue. – ilomambo Mar 10 '14 at 17:14
  • I understand; I still think it would be nice to figure out what the original problem was. I assume that the image above it the "works" case. What was the order of elements in the classpath when it didn't work? And did you change anything else (adding/removing an element)? Did the elements on the "Libraries" tab change? – Aaron Digulla Mar 11 '14 at 08:35
  • 1
    I tried to do one better and recreate the failure, but I did not succeed. The posted pics are indeed of the working case. I think before that the added libraries (like Xerces and JUnit4) were at the bottom, and the Android dependencies and private libraries were at the top. – ilomambo Mar 11 '14 at 12:54
  • I did get a similar error when I moved Xerces to the bottom, it did not find its methods at runtime, but it compiled OK, like my original example in this post. When moved Xerces to the top the test run OK. Hope this helps. – ilomambo Mar 11 '14 at 12:56
  • Well, Xerces is only on one of the two classpaths (see your question). But moving elements should only have an effect if one of the Android libraries already contains Xerces or JUnit and I'm pretty sure they don't. – Aaron Digulla Mar 11 '14 at 13:14
  • I encountered this same problem and the same fix worked for me. But I agree the export order shouldn't matter as the only related class I can find in android.jar is junit.framework.Assert. Could there be a bug in the Android class loader? – gcooney May 27 '14 at 13:38
  • @gcooney: I suspect a security feature; maybe the package is signed or something. – Aaron Digulla May 28 '14 at 14:08