0

Java assert statements are selectively enabled/disabled, based on config flags (eg, -ea). I read online that with JUnit assertions (eg, Assert.assertTrue), you don't need to worry about managing the assertion-config yourself. What exactly does this mean? Either:

1) JUnit assertions (mixed together with Prod code) are never disabled. They behave just like Validate statements, and always get run.

or

2) The JUnit test framework automatically enables all JUnit assertions when running JUnit tests. Whenever the application/code is run outside of JUnit, the JUnit assert methods do nothing at all.

or

3) JUnit assertions are always enabled/disabled by default, but there is a custom config/flag that can be used to disable/enable them

Which of the above is true?

--

Edit: Changed the wording a little bit to clear up any ambiguity.

Improve this question
7
  • 5
    JUnit tests are never deployed to production (because they are not part of the application), so it doesn't matter. Commented Aug 8, 2015 at 21:53
  • 3
    JUnit should only be used for unit testing, not in prod Commented Aug 8, 2015 at 21:54
  • 3
    JUnit assertions and Java asserts are too completely different things. JUnit assertions are simple method calls from indide the unit tests. They don't exist in the production code, which doesn't use JUnit. Commented Aug 8, 2015 at 21:54
  • 1
    @RvPr: IMHO there is no conflict with the SO answers linked above. It's just the term 'assertion' used in different situations. The assert keyword is usually used to guard certain functionality (input validation in terms of unexpected input values). Whereas JUnit assertions are used to check the outcome of a certain functionality. Commented Aug 9, 2015 at 6:17
  • 1
    @RvPr: I still do not agree. The second question explicitly focuses on tests whereas you ask about production code. Second, I did not recommend to use assert - in fact I try to avoid it... Commented Aug 9, 2015 at 13:49

2 Answers 2

Reset to default
2

This question seems to have opened up a can of worms with regards to coding-guidelines on when to use/not to use asserts. I'll post here the answer to my immediate question regarding whether JUnit Assert statements get disabled. Further down, you will find a discussion on the philosophical aspects of using assertions.

Summary: JUnit assert statements are never disabled, even when running in production with the disable-assertions flag.

Experiment: Created a small main function which throws an error in the very first line. The error was implemented in various different ways. I then ran the application from the command-line like so: mvn clean package; java $JAVA_OPTS -cp ....

  1. Induced error by throwing IllegalArgument exception. Application failed with IllegalArgument exception.

  2. Induced error by adding assert false and ran with assertions enabled (-ea). Application failed.

  3. Induced error by adding assert false and ran with assertions disabled (-da). Application succeeded.

  4. Induced error by adding Assert.assertTrue(false); and ran with assertions enabled (-ea). Application failed with AssertionError.

  5. Induced error by adding Assert.assertTrue(false); and ran with assertions disabled (-da). Application failed with AssertionError.

Did a quick google search to see if there's any way to disable JUnit.Asserts. Didn't find anything. If anyone knows of a way to do so, please let me know, because I believe it's an important distinction.

Conclusion: assert keywords can be enabled/disabled using the -ea commandline flag. JUnit.Asserts cannot be enabled/disabled. If you want to add assertions to your production code, then this becomes a very important distinction. If you want the ability to disable them, use the assert keyword. If you want something that you know will always be enabled, then consider JUnit.Assert, or some other similar framework that throws AssertionErrors.

Regarding the philosophy behind assert usage:

  1. It's good to add assertions of some form to your production code. See: https://docs.oracle.com/javase/8/docs/technotes/guides/language/assert.html#usage

Putting Assertions Into Your Code. There are many situations where it is good to use assertions, including: Internal Invariants Control-Flow Invariants Preconditions, Postconditions, and Class Invariants

  1. JUnit Asserts cannot be treated as a universal replacement for java assert keywords. The latter gives you the power to disable them, and the former doesn't. Hence, there is a design choice to be made in choosing which of the 2 to use.

  2. Exceptions and Assertions serve very different purposes and should not be used interchangeably. The following discussion clarifies this further: When to use an assertion and when to use an exception

Related StackOverflow discussions:

assert vs. JUnit Assertions

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

IMO, your conclusion is wrong. Classes in *.junit.* packages should not be used in production code (JUnit is a test framework). In case you want runtime assertions I'd rather use assert (which I do not like) or another framework (e.g. docs.spring.io/spring/docs/current/javadoc-api/org/…). Of course, one could technically use those classes - as you wrote it is a matter of code conventions / guidelines...
@home Just so we're on the same page: assuming you want an assertion that is never disabled, is there any functional reason not to use JUnit.assert in production? I'm assuming that your objection is philosophical (JUnit classes should only ever be used in tests), and not functional.
@home Besides spring.Assert, is there any other assert-framework that is just as good as JUnit's? Using spring.assert in code not related to Spring seems equally icky for the same reasons as using JUnit.Assert. Using the assert keyword seems like a pain because of it's non-descriptive error messages and lack of functionality that JUnit.Assert offers.
@home Sorry for the many replies! Reading further on SpringFramework.Assert, it doesn't actually throw AssertionErrors, it throws Exceptions. This essentially makes it analogous to a Validate statement, and not analogous to assertions. I think there are important distinctions to be made between exceptions vs assertions, and they shouldn't be used interchangeably. This discussion clarifies that further: stackoverflow.com/questions/1957645/…
If you want an assertion in production that can never be turned off, just do throw new AssertionError("message")
|
1

I think you're confused between JUnit assertions and Java's built in assertions.

  1. JUnit assertions are methods that throw an AssertionError exception and should only be used in your test code. JUnit code should not be used in production, only when running your JUnit tests during/between builds. The method names are named like assertEquals( expected, actual) and assertNull(Object) etc. You can't disable these assertions since they are method calls. Also your test code would be pretty useless if you could disable all the JUnit assert methodcalls.

  2. Java's built in assertion is a boolean expression preceded by the assert keyword. If the expression returns false, then it too throws an AssertionError. This kind of assertion can be disabled in production to help speed up your code or turned on to help track down bugs. You can read more about the built in Java assert in the Java Programming Guide

Improve this answer

4 Comments

When you say "JUnit assertions should only be used in test code," are you saying that they should only be used inside of unit/integration tests? If so, that seems to conflict heavily with the recommendations given here: stackoverflow.com/questions/1957645/… Ie, assertions can/should be placed inside your production code, in order to assert that certain code invariants are maintained
@RvPr That question is talking about Java assertions, not JUnit assertions. And yes, JUnit is not normally used in production code. JUnit assertions are used for tests.
@MatthewFarwell Is it your recommendation that we use JUnit Asserts inside of test code, and assert keywords inside of production code?
Yes. Use JUnit assertions in your tests. I personally don't use Java assertions anywhere, but some people do.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.