100

Today I saw a JUnit test case with a java assertion instead of the JUnit assertions—Are there significant advantages or disadvantages to prefer one over the other?

Muhd
  • 24,305
  • 22
  • 61
  • 78
Robert
  • 8,406
  • 9
  • 38
  • 57
  • There are absolutely factual differences between JUnit assertions and Java 'assert' keyword. This is not at all an opinion-based question. – Thomas W Jan 10 '18 at 23:59

6 Answers6

107

In JUnit4 the exception (actually Error) thrown by a JUnit assert is the same as the error thrown by the java assert keyword (AssertionError), so it is exactly the same as assertTrue and other than the stack trace you couldn't tell the difference.

That being said, asserts have to run with a special flag in the JVM, causing many tests to appear to pass just because someone forgot to configure the system with that flag when the JUnit tests were run - not good.

In general, because of this, I would argue that using the JUnit assertTrue is the better practice, because it guarantees the test is run, ensures consistency (you sometimes use assertThat or other asserts that are not a java keyword) and if the behavior of JUnit asserts should change in the future (such as hooking into some kind of filter or other future JUnit feature) your code will be able to leverage that.

The real purpose of the assert keyword in java is to be able to turn it off without runtime penalty. That doesn't apply to unit tests.

Sinc
  • 553
  • 1
  • 8
  • 31
Yishai
  • 90,445
  • 31
  • 189
  • 263
28

I prefer JUnit assertions as they offer a richer API than the built-in assert statement and, more importantly do not need to be explicitly enabled unlike assert, which requires the -ea JVM argument.

Adamski
  • 54,009
  • 15
  • 113
  • 152
  • 1
    `-ea` is always enabled in `mvn test`, no need for `-ea`. Richer api, good catch. Sometimes I think API is misused in test because it is not part of the application (a in api), I prefer to call it just richer methods. – Grim Jan 11 '18 at 03:23
22

When a test fails you get more infomation.

assertEquals(1, 2); results in java.lang.AssertionError: expected:<1> but was:<2>

vs

assert(1 == 2); results in java.lang.AssertionError

you can get even more info if you add the message argument to assertEquals

starmer
  • 2,197
  • 19
  • 12
  • 10
    try `assert 1==2: "1 is not 2";`. – Grim Dec 08 '15 at 10:03
  • @PeterRader Try the assert keyword when -ea is not enabled. Or better yet, use JUnit assertions which always work. – Thomas W Jan 10 '18 at 23:57
  • 1
    @ThomasW when -ea is not enabled its not a test. JUnit asserations does not always work, they only work if you decide to use JUnit what is a framework, and in case of maven a maven dependency, a maven dependency that must be in test-scope only. We have two sides here: What do you prefer? **1st Side**: Use a framework, as an dependency in test-scope only, that must be downloaded, that eclipse let you use in classes that are not in the src/main-folder but wont compile there because maven have junit only in test-scope or **2nd Side**: Use the build-in stuff. – Grim Jan 11 '18 at 03:18
  • 1
    @PeterRader This question is about JUnit test cases. In that context JUnit or similar assertion class should be used, because these are always enabled. I have personally been caught out by Java 'assert' keyword not being enabled in the past, and do not believe unreliable assertions have a place in test code. – Thomas W Jan 11 '18 at 23:26
  • In the separate context of assertions in feature code -- important to robust programming practice, though not actually the topic of the question -- both Spring and Google Guava have assertion classes which are always enabled. I recommend generous use of these as parameter & state preconditions to ensure correctness. Beyond that, in performance-critical areas, there can be a small area where the Java `assert` may be preferable -- for correctness checks which *would* impact performance and are thus best disabled by default. However my experience is that most assertions should be always-on. – Thomas W Jan 11 '18 at 23:32
  • @ThomasW Yes, in Eclipse there was a bug (reported by me), where -ea did not work by default in IDE testing mechanism, its fixed now. So assert is not unreliable. Unreliable are developers who define antipatterns out of bugs. A xy-antipattern. – Grim Jan 12 '18 at 08:37
  • @PeterRader Please stick to facts -- you are veering into impolite personal comments. My recommendation remains to use assertion classes for most usage; Spring, Google Guava, JUnit and TestNG frameworks all agree on this. Please don't contact me again. – Thomas W Jan 15 '18 at 02:57
  • It was impolite but since he agree that it is not a antipattern it was not personal. – Grim Jan 15 '18 at 08:06
8

I'd say use JUnit asserts in test cases, and use java's assert in the code. In other words, real code shall never have JUnit dependencies, as obvious, and if it's a test, it should use the JUnit variations of it, never the assert.

Bruno D. Rodrigues
  • 370
  • 4
  • 9
0

I would say if you are using JUnit you should use the JUnit assertions. assertTrue() is basically the same as assert, Otherwise why even use JUnit?

CheesePls
  • 887
  • 1
  • 6
  • 17
  • 4
    You would use JUnit for the test running framework. Asserts are really a small part of the value JUnit gives you. JUnit without `Assert` would require more boilerplate. `assert` without JUnit would require you to write a whole framework. – Yishai Jun 03 '10 at 13:41
  • 1
    I was more saying if you're going to use the tool, USE THE TOOL. regular old assert statements seem a tad silly in JUnit test cases. They belong in with the actual code in my opinion. – CheesePls Jun 03 '10 at 14:01
  • 1
    @CheesePls "regular old assert statements" are in fact more recent than JUnit asserts. – dolmen Aug 09 '12 at 09:55
0

This may not apply if you exclusively use stuff that's shiny and new, but assert was not introduced into Java until 1.4SE. Therefore, if you must work in an environment with older technology, you may lean towards JUnit for compatibility reasons.

Dan Coates
  • 2,002
  • 3
  • 17
  • 21