• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Can deprecated ExpectedException.none() be still used as long as JUnit4 is used?

 
Ranch Hand
Posts: 50
Android Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When implementing JUnit4 testcases I noticed that ExpectedException.none() is deprecated.

I know that @Rule etc. has to be changed when porting testing code to JUnit5, but can anybody say whether the none() method can be still used as long as JUnit4?
In addition I am a bit curious why  ExpectedException.none() has been deprecated.


 
Saloon Keeper
Posts: 24315
167
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Probably because it's redundant. If no Exceptions are expected, then why say no Exceptions are expected?

If I expect a unit test to throw an exception I'd generally catch and verify it. Otherwise, I'd assume the test failed. Wouldn't need to actually say it.
 
Marshal
Posts: 22453
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tim, this was the way in JUnit 4.12 and before to perform validation on exceptions (see https://junit.org/junit4/javadoc/4.13/org/junit/rules/ExpectedException.html):

If the code didn't thrown an exception, or if the thrown exception didn't match the expectations, the test would fail instead of produce an error.

Roland, JUnit 5 introduced assertThrows, and this has been backported to JUnit 4.13. The new way to do the same is as follows:

By switching to assertThrows you will make the transition to JUnit 5 easier, where ExpectedException no longer exists. However, JUnit 4 will keep supporting it.

Note: if you're not using Java 8 or up, you can still use anonymous sub classes in assertThrows.
 
Roland Mueller
Ranch Hand
Posts: 50
Android Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your answers!

Some note about the given case: it's not me who will decide about the time when to port this to JUnit5. If the abovementioned construct will be invalid still in JUnit4 time the only alternative I see would be to go back to stone age thus. JUnit3:

 
Rob Spoor
Marshal
Posts: 22453
121
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I never said it was invalid. Both ExpectedException and assertThrows work in JUnit 4.13. You can keep using the deprecated code, and replace it gradually with assertThrows. The switch to JUnit 5 is still pretty big, it took me a few hours to migrate just a few small projects. That was mostly due to @Test(expected = ...) and ExpectedException and replacing them with assertThows. The other major issues I had were:
  • The replacement of Runners with Extensions. Both Spring and Mockito (two out of three Runners I've used most often) have Extensions as well.
  • The way parameterized tests are executed. Parameterization no longer occurs per class (using the Parameterized Runner), but per method with either @ParameterizedTest or using dynamic tests with @TestFactory.

  • So sticking with JUnit 4 is not a bad thing for existing projects. Just don't go back to JUnit 3 constructs, that will really hurt you in the end. The upgrade to JUnit 5 can come at any time. I do suggest using JUnit 5 for new projects from the start though.
     
    Roland Mueller
    Ranch Hand
    Posts: 50
    Android Java Linux
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Rob Spoor wrote:I never said it was invalid. Both ExpectedException and assertThrows work in JUnit 4.13. You can keep using the deprecated code, and replace it gradually with assertThrows. ....


    OK. Thanks! That's the best solution in this case. I was not aware that the assertThrows() construct can be already used in JUnit4.
     
    Rob Spoor
    Marshal
    Posts: 22453
    121
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Yeah, I was surprised as well when I saw it pop up in JUnit 4.13. I guess it's a feature too good to not backport.
     
    reply
      Bookmark Topic Watch Topic
    • New Topic