2

I have a similar problem than this question.

I would like to implement the selected answer (the other ones don't work or apply to my case).

The problem is that the enum I want to redefine is actually inside a class.

package a.package.i.dont.own;

public class AClass {
   public enum AnEnum {
      A,
      B
   }

  // Here a bunch of stuff I'm using and don't want to redefine
}

The corresponding code I want to test:

public String someMethod() {
   return switch(aMethodThatReturnsAnEnumValueFromContext()) {
      case A -> "foo";
      case B -> "bar";
      default -> null;
   }
}
Christophe Broeckx
  • 334
  • 2
  • 10
  • What is then the problem? – Youcef LAIDANI Nov 17 '22 at 15:36
  • 2
    @YoucefLaidani to apply the suggested solution he should redefine not only the enum but also the owner class, that he doesn't want to redefine because he's using it as is. – Matteo NNZ Nov 17 '22 at 15:37
  • If I may suggest: I guess the problem you have is that since your method switches directly on the enum, you have no way to reach the default branch but at the same time, you want to test the default branch to test what you do if the enum changes one day out of your control. If it is the case, and if your code is really like it appears, have you thought of simply mocking someMethod() to return null (what you'd return on the default branch of the switch)? – Matteo NNZ Nov 17 '22 at 15:53
  • You are correctly assuming, @MatteoNNZ. But I want to test someMethod()... If I mock it, how am I testing it? – Christophe Broeckx Nov 17 '22 at 15:57
  • @ChristopheBroeckx is your "someMethod" containing other code that you're not showing? Because what you're showing is a simple switch on the enum value, so you can test it for normal values of the enum and mock it for handling the default branch. If it's not the case, you can still extract the return switch... into a separate method and mock that part only to actually test the rest. – Matteo NNZ Nov 17 '22 at 15:58
  • @MatteoNNZ yes there is more to it. But my case here is not to test what happens elsewhere when the default case is reached. I should have put an exception instead of a null to better illustrate it. My point is only to reach the required conditional coverage that is needed for the project :/ – Christophe Broeckx Nov 17 '22 at 16:16
  • 1
    Can the enclosing class be dynamically proxied? If so, you can imagine to redefine the whole class with the enum, and then to redirect each call to the original class through the dynamic proxy and only keep the overridden enum definition. But generally speaking, code coverage is something we can always negotiate, I see why you want to test that specific case but if to test one simple exception throw you have to do all this work, you should wonder whether it's worth to leave it untested... – Matteo NNZ Nov 18 '22 at 06:50
  • @MatteoNNZ Yes that could work indeed. That's not very pretty but it's that or change the conditional coverage requirement. In my case I was finaly able to challenge it, so I'm fine, but others might not have that possibility. Thank you for your help :) – Christophe Broeckx Nov 30 '22 at 15:34

0 Answers0