Question

I’m currently trying to build a more or less complete set of unit tests for a small library. Since we want to allow different implementations to exist we want this set of tests to be (a) generic, so that we can re-use it to test the different implementations and (b) as complete as possible. For the (b) part I’d like to know if there is any best-practice out there for testing enum types. So for example I have an enum as follows:

public enum Month {
    January,
    February,
    ...
    December;
}

Here I want to ensure that all enum types really exist. Is that even necessary? Currently I’m using Hamcrests assertThat like in the following example:

assertThat(Month.January, is(notNullValue()));

A missing “January” enum would result in a compile time error which one can fix by creation the missing enum type.

I’m using Java here but I don’t mind if your answer is for a different language..

Edit:

As mkato and Mark Heath have both pointed out testing enums may not be necessary since the compiler won’t compile when you are using an enum type which isn’t there. But I still want to test those enums since we want to build a seperate TCK-like test.jar which will run the same test on different implementations. So my question was more meant to be like: What is the best way to test enum types?

After thinking about it a bit more I changed the Hamcrest statement above to:

assertThat(Month.valueOf("January"), is(notNullValue()));

This statement now throws a NPE when January is not there (yet). Is there anything wrong with this approach?

Answer 1

For enums, I test them only when they actually have methods in them. If it’s a pure value-only enum like your example, I’d say don’t bother.

But since you’re keen on testing it, going with your second option is much better than the first. The problem with the first is that if you use an IDE, any renaming on the enums would also rename the ones in your test class.