4

I need to know how to test the default case in a switch statement with junit. I can't change the code itself and I'm trying for 100% coverage but I don't know how to test my default. Helps?

public Hello helloSwitch() {
        Hello hi = Hello.A;
        switch (this) {
        case A:
            hi = Hello.B;
            break;
        case B:
            hi = Hello.C;
            break;
        case C:
            hi = Hello.A;
            break;
        default:
            hi = Hello.A;
            break;
        }

I had to modify the code a fair bit so sorry that it looks silly. I just need to know how to write a junit to test the default, I've tested everything else.

I can't change this code.

Edit: changed

Edit: This code isn't important I jut need to know how to write the unit test for the default

Edit: I can't change, the code itself, I'm only writing the tests. I need 100% coverage though.

Meow
  • 67
  • 1
  • 1
  • 4
  • Your code sample is missing some necessary info. How is `hallo` being set? – mauzel Jan 25 '15 at 18:50
  • Possibly related: http://stackoverflow.com/questions/25929351/unit-test-for-enum-value-that-doesnt-exist – assylias Jan 25 '15 at 18:56
  • If the code is unreachable, then you can't write a test for it. Having 100% code coverage isn't a useful goal IMHO. If you can change the code (which is almost always the case) and the default case cannot be reached, then throwing `AssertionError` or `IllegalArgumentException` could be a good alternative than doing a senseless default. – NamshubWriter Jan 25 '15 at 19:15
  • 1
    Possible duplicate of [Mocking Java enum to add a value to test fail case](http://stackoverflow.com/questions/5323505/mocking-java-enum-to-add-a-value-to-test-fail-case) – CoronA Jul 04 '16 at 09:44

3 Answers3

1

Let me assume that 'hallo' is a variable set somewhere outside the given method. Let me further assume that the Enum type currently only allows values present in the switch statement. In this case you can use "null" to trigger the default case. In this case the default statement is unreachable and should not be there at all. While there might be ways to still "test" this - meaning to execute the code running a test - this would not add any benefit. If you have more enum constants available than pick any covered by the default case.

As some already have mentioned:

  • dead code cannot and should not be tested but removed.
  • 100% test coverage sounds nice but usually is not a realistic or sensible goal
  • in my opinion test shouldn't even know about the code in a method but test the method as a black box.
Christian Frommeyer
  • 1,390
  • 1
  • 12
  • 20
  • I don't think that will work - the null will throw a NPE at the switch, not fall through to the default. – Leif Jun 29 '16 at 01:14
  • Thank you Leif. That is of course not possible. I edited my answer. – Christian Frommeyer Jun 29 '16 at 05:31
  • 1
    I would like to add that
    1. unit tests are white box, based entirely on the code itself, where code coverage is the goal.
    2. default cases in switch statements are encouraged because you can handle the case where you added a new valid value, but forgot to add code for it     – Janin May 23 '20 at 00:04
  • Some comments to the claims you made: 1. Unit test need to be white box with regard to the Unit that is tested. But they don't necessarily need to know every detail of the code. Further more the less tightly coupled a test is to the implementation the more it is useful as a harness for refactoring. If code coverage is the only goal than the test wouldn't necessarily do any good. It is pretty easy - and in fact done far too often - to write test with amazing code coverage that actually test nothing (no asserts ...). – Christian Frommeyer May 24 '20 at 16:49
  • To 2nd: This is in fact true where the compiler can not detect missing cases. Like if you are switching over integers, characters or even Strings... For Enums the compiler can detect missing cases which is in fact one of the large benefits of using Enums. Building fallback logic early will cause more harm than good in this case. The better solution is to trust this to the compiler (please note that already in my answer I was talking about situations where all values get handled -> it is likely that a new one would need special handling to) – Christian Frommeyer May 24 '20 at 16:56
0

If you are using JaCoCo then maybe vote for this improvement to ignore default cases which can't be covered: https://github.com/jacoco/jacoco/issues/1211

Hollerweger
  • 975
  • 1
  • 13
  • 32
-3

visit this link can help you : [JUnit is a standardized framework for testing Java units (that is, Java classes). JUnit can be automated to take the some of the work out of testing.

Imagine you’ve created an enum type with three values: GREEN, YELLOW, and RED. Listing 1 contains the code: http://www.dummies.com/programming/java/using-junit ]1

essid
  • 9
  • 1