-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Null Pointer exception assertArrayEquals with no message. #1178
Comments
Can you please provide a test case to illustrate your problem? |
On Tue, Jul 7, 2015 at 12:27 PM, Marc Philipp notifications@github.com
|
package sandbox;
import static org.junit.Assert.assertArrayEquals;
import org.junit.Test;
import org.junit.runner.JUnitCore;
import org.junit.runner.Result;
public class Snippet {
@Test
public void testJunit() {
assertArrayEquals(new Boolean[] { true }, new Boolean[] { false });
}
public static void main(String[] args) {
Result result = JUnitCore.runClasses(Snippet.class);
result.getFailures().get(0).getException().printStackTrace(System.out);
}
} Running this as a Java application prints
|
I cannot reproduce this issue. How do you run your tests? Do you have a stacktrace? |
They're run from inside netbeans, and it is a gradle project. It doesn't On Wed, Jul 8, 2015 at 2:18 PM, Marc Philipp notifications@github.com
|
Sorry, it looks like I didn't read this stack trace nearly close enough. Perhaps it's somewhat of a gradle bug, but if the toString is just getting If you can verify toString() does what you guys intended, then this can be Could not determine failure message for exception of type java.lang.NullPointerException On Thu, Jul 9, 2015 at 9:55 AM, Bob Saget aflred.g.fakename@gmail.com
|
Are you using 4.12 or a 4.12-beta? |
We had problems with Gradle due to serialization issues in the first two 4.12-betas, see #976. |
What version of Gradle are you using -- and what version of JUnit does it use? It could be a regression introduced in #836. |
Sorry, work is blowing up right now... odd thing to have in bug report log, Will get back on this soon. On Thu, Jul 9, 2015 at 11:17 AM, Marc Philipp notifications@github.com
|
Build.gradle testCompile "junit:junit:4+" And the package manifest Manifest-Version: 1.0 On Thu, Jul 9, 2015 at 3:57 PM, Bob Saget aflred.g.fakename@gmail.com
|
My gradle is a bit old, 2.2.1... I forgot I use a standalone and not the On Fri, Jul 10, 2015 at 4:43 PM, Bob Saget aflred.g.fakename@gmail.com
|
Indeed, reverting to 4.11 solves the issue. |
Gradle 2.2 relies on junit 4.11 for its java plugin I believe so if you run
you'll see two log lines that specify the application and implementation classpaths. The application classpath will include the junit jar with the version your project specified and the implementation classpath includes junit-4.11 which is bundled with gradle itself. For some reason, when creating the test report, it uses the junit jar bundled with gradle, not the one you specified in the testCompile gradle directive. I'm not exactly sure why that happens and tried looking for a way to set preference to junit versions with gradle's java plugins, but didn't look too hard for it (hoping someone can help with this perhaps?). Instead, an upgrade to gradle 2.13 solved the problem entirely since it bundles junit 4.12 with it. Upgrading gradle might not be the best fix since we're still relying on gradle itself to be bundled with the junit version with which we want to run our test (to generate the test report without throwing the npe, or any other backwards incompatibility related problems). |
As pointed out in #976 (comment) 4.12 broke serialization compatibility with earlier versions in |
Ah, that makes sense -- to not have serialization incompatibility at all across (the minor) versions. I'm not too familiar with the development process of this project -- since the issue is set as a milestone of 4.13, you'd expect the bugfix to be available for that version (and not back patched into 4.12)? |
…tCause()) to avoid npe and unused field warnings, respectively Issue junit-team#1178, junit-team#976
Add back field fCause, initialize and use in the constructor (via initCause()) to avoid npe and unused field warnings, respectively Issue junit-team#1178, junit-team#976
It seemed like this fix would probably have to be folded in 4.13 so created a pullrequest on top of master: #1315 Tested with gradle 2.2, running a test that expected the arraycomparisonfailure thrown:
Let me know if there's something off. I was thinking of adding serialization tests but held off on it since it would probably require pulling down junit-4.11 and wrangling both packages across the execution? |
Since 4.12 has been released last December and 4.13 will be backwards compatible I don't see a point in shipping a 4.12.1 for this fix.
Thanks for the pull request! I've added a comment on #1315. |
Add back field fCause, initialize and use in the constructor (via initCause()) to avoid npe and unused field warnings, respectively Issue junit-team#1178, junit-team#976
…1315) * Add back field fCause, initialize and use it in the constructor (via initCause()) to avoid NPE and unused field warnings, respectively. * Override getCause() to allow fallback to the deprecated fCause field. * Run tests around possible forward incompatibility of the class from r4.11, 4.12. Fixes junit-team#1178.
When assertArrayEquals (at least for Boolean[]) fails the assert, it throws a null pointer exception looking for a message. This is, of course, when using the prototype that has no message. You'll still get the line number for the failure, you'll still probably just debug focused test method, and be on your merry way, but just technically it's not quite the best/correct behavior.
Thanks!
Update: this is for 4.12
The text was updated successfully, but these errors were encountered: