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.
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.
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."
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.