This week's book giveaway is in the Reactive Progamming forum.
We're giving away four copies of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams and have Adam Davis on-line!
See this thread for details.
Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming 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
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

better way of returning element

 
author & internet detective
Posts: 39530
776
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?

 
Marshal
Posts: 14040
234
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: 39530
776
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.

 
Sheriff
Posts: 6408
1132
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: 21803
104
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: 39530
776
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
Marshal
Posts: 14040
234
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: 39530
776
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
Marshal
Posts: 14040
234
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: 39530
776
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
    Marshal
    Posts: 14040
    234
    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.
     
    Did Steve tell you that? Fuh - Steve. Just look at this tiny ad:
    Java file APIs (DOC, XLS, PDF, and many more)
    https://products.aspose.com/total/java
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!