Obecnie próbuję zbudować mniej lub bardziej kompletny zestaw testów jednostkowych dla małej biblioteki. Ponieważ chcemy, aby istniały różne implementacje, chcemy, aby ten zestaw testów był (a) generyczny, abyśmy mogli go ponownie wykorzystać do testowania różnych implementacji i (b) jak najbardziej kompletny. W części (b) chciałbym się dowiedzieć, czy istnieje jakaś najlepsza praktyka do testowania typów wyliczeniowych. Na przykład mam enum w następujący sposób:

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

Tutaj chcę upewnić się, że wszystkie typy wyliczeniowe naprawdę istnieją. Czy to nawet konieczne? Obecnie używam HamcrestsassertThat jak w poniższym przykładzie:

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

Brakujący enum „Styczeń” spowodowałby błąd czasu kompilacji, który można naprawić, tworząc brakujący typ wyliczenia.

Używam tutaj Java, ale nie mam nic przeciwko, jeśli twoja odpowiedź dotyczy innego języka.

Edytować:

Jako, że mkato i Mark Heath wskazywali, testowe wyliczenia mogą nie być konieczne, ponieważ kompilator nie skompiluje się, gdy używasz typu enum, którego tam nie ma. Ale nadal chcę przetestować te wyliczenia, ponieważ chcemy zbudować oddzielny plik test.jar podobny do TCK, który uruchomi ten sam test na różnych implementacjach. Moje pytanie miało więc wyglądać następująco: Jaki jest najlepszy sposób testowania typów wyliczeniowych?

Po zastanowieniu się nad tym nieco zmieniłem powyższe stwierdzenie Hamcresta na:

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

Ta wypowiedź rzuca teraz NPE, gdy nie ma jeszcze stycznia. Czy jest coś nie tak z tym podejściem?