Win a copy of Cloud Native PatternsE this week in the Cloud forum
or Natural Language Processing in the AI/ML forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Paul Clapham
  • Knute Snortum
  • Rob Spoor
Saloon Keepers:
  • Tim Moores
  • Ron McLeod
  • Piet Souris
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

better way of returning element

 
author & internet detective
Posts: 39392
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've found myself writing code like this a few times in JUnit tests. Is there a better way of writing it?

 
Sheriff
Posts: 13551
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would you purposely throw an RTE in a test though?
 
Jeanne Boyarsky
author & internet detective
Posts: 39392
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Because I can't call fail() in there. If I wasn't using streams, I'd call fail or assert. I'm trying to make the unit test fail if the value isn't found. Hmm. That question suggests that this approach is better.

 
Marshal
Posts: 6367
1123
IntelliJ IDE jQuery Eclipse IDE Postgres Database Tomcat Server Chrome Google App Engine
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about...

??
 
Sheriff
Posts: 21774
103
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was thinking of doing what OpenJDK has (from file test/jdk/java/util/Optional/Basic.java):

Applied to Jeanne's code it would become this:

But I like Devaka's example better, it's much clearer.
 
Jeanne Boyarsky
author & internet detective
Posts: 39392
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob: I like that! It calls fail and doesn't introduce extra complexity to the code.

Devaka: I had considered and rejected that idea. Because then I need to add the extra variable (optional vs the one I want.) And also, I need to call get later unconditionally. I'd rather not sprinkle that in my code.
 
Junilu Lacar
Sheriff
Posts: 13551
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kind of sounds like there's logic that needs to be pushed down from the test into the object under test. I'm saying this based. I get a whiff of a code smell from the statement "I need to call get later unconditionally. I'd rather not sprinkle that in my code."
 
Jeanne Boyarsky
author & internet detective
Posts: 39392
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There isn't an object under test. These tests are calling REST APIs to check data in a system.  Like a monitoring thing.

For example, I want to get a user from the REST API that returns a list of all users and check the roles it is.
 
Junilu Lacar
Sheriff
Posts: 13551
223
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So these aren't unit tests then? More like contract tests? If so, there's still a smell of testing at the wrong level. Would you mind showing what a couple of these tests look like in their entirety?
 
Jeanne Boyarsky
author & internet detective
Posts: 39392
763
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:So these aren't unit tests then? More like contract tests?


Sorta. This is for a COTS application. So we are testing that the configuration of the application is right. So we don't control the REST API we are calling.

Junilu Lacar wrote:If so, there's still a smell of testing at the wrong level. Would you mind showing what a couple of these tests look like in their entirety?


My employer doesn't allow us to post code publicly. But here's the gist:

  • Get credentials
  • Call REST API to get list of users
  • Get user I am trying to account (in this case one that is used to connect two systems)
  • Fail if user not found because config is wrong
  • Assert roles are correct
  •  
    Junilu Lacar
    Sheriff
    Posts: 13551
    223
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ok, thanks for that. Since I still don't have a grasp of the entire context, however, I still have some reservations. Keep in mind that they are still just whiffs of "smells"; they may or may not indicate underlying problems.

    1. That there is no object under test raises a slight concern that the test is too reliant on implementation details, e.g., the statements that you're asking about here. I prefer to test behaviors and push implementation details into the object under test. My preference would be to set up a test like this:

    2. If there are many aspects of configuration to verify, then the above test might be broken down even further:

    Note that while the above appears to be in Gherkin format, I'm not suggesting to use Cucumber. This just captures the essence of the test and the level of abstraction I'd shoot for. My reservation really stems from seeing the kind of code we have discussed above in tests. My gut reaction is that kind of code should be encapsulated and hidden behind a method call to the object under test.

    Of course, you may have compelling reasons that haven't been surfaced here for having that code in a test rather than encapsulated in an object.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!