2015-07-09 1 views
1

Предположим, у меня есть метод с некоторыми параметрами, аннотированными аннотацией javax @Nonnull.Intellij IDEA предупреждения для аннотации @Nonnull в модульных тестах

public Something supply(@Nonnull SomeObject someObject) { 
    (...) 
    if (someObject == null) throw new ValidationException("Required parameter is null"); 
    (...) 
} 

IDE правильно уведомляет меня, когда я пытаюсь вызвать этот метод с явным пустым аргументом, например:

somethingSupplier.supply(null); 

Теперь то, что я хочу сделать, это создать модульное тестирование, который проверяет надлежащее исключение будет сброшен, если по какой-либо причине аргумент, переданный этому методу, окажется нулевым (скажем, это какое-то исключение проверки).

Если я попытаюсь вызвать этот метод, как в приведенном выше примере, IDE предупредит меня о передаче null в @Nonnull ... но это именно то, что я хочу сделать здесь. Я могу аннотировать вызов или метод или даже тестовый класс с помощью @SuppressWarnings("ConstantConditions"), но он загромождает код, и я не могу получить предупреждение о других непреднамеренных ошибках, которые я делаю в коде.

Итак, вопрос в том, можно ли как-то отключить проверку для @Nonnull в тестовых классах? Или, может быть, я не должен полностью тестировать эти случаи?

+1

Аннотации '@ Nonnull' не означают, что' NullPointerException' всегда вызывается для аргумента 'null'. Фактически, для «частных» методов я рассматривал бы такое требование как пустую трату ресурсов, поскольку проверка должна гарантировать во время компиляции, что «null» никогда не передается методу. Таким образом, NPE * могут возникать как побочный эффект операции при передаче «null», но явные тесты должны быть устаревшими. – Holger

+0

Хорошо, допустим, этот метод является общедоступным. Кроме того, в кубе этого метода в какой-то момент возникает какое-то специальное правило ValidationException, которое может быть важно для меня (для отката или sth, как это). Я отредактировал вопрос. – mareckmareck

ответ

5

Если вы хотите проверить поведение кода для ошибочных случаев, неизбежно ли создать код, который является ошибочным в отношении правил тестируемого кода. Если эти правила могут быть проверены IDE, очевидно, эти проверки обнаружат, что и подавление этих предупреждений неизбежно.

Как и при подавлении предупреждений, вы должны попытаться сузить код, для которого подавление применяется как можно больше. Например, вы можете создать фабричный метод в коде тестирования, обеспечивающей такую ​​недопустимую величину, которая летает под радаром проверки на основе системы типа:

class IllegalValue { 
    @SuppressWarnings("ConstantConditions") 
    static @Nonnull <T> T sneakyNullReference() { 
     return null; 
    } 
} 

Таким образом, вы ограничили подавляя этот небольшой один метод. В ваших тестовых случаях вы можете использовать IllegalValue.sneakyNullReference() для тестирования кода для его поведения null без дополнительного подавления и, следовательно, правильно получать предупреждения при использовании null в неподходящих местах в тестовом коде. Я настоятельно рекомендую никогда не сохранять результат sneakyNullReference() в переменную, но всегда указывать, где это необходимо, для ясности.

I.e. в рамках теста вашего вопроса код должен выглядеть

somethingSupplier.supply(IllegalValue.sneakyNullReference()); 

поэтому читатель сразу понимает, что здесь испытывались ...

+0

Это похоже на довольно приличную идею, я попробую, спасибо! – mareckmareck

+1

@mareckmareck: замена Java '@ Nonnull' и' 'не требуется в Java 8. Я использовал этот порядок, потому что имеет смысл рассматривать его как аннотацию типа, а не аннотацию метода. – Holger

+0

Вы правы ... по какой-то причине IDEA не распознает его как правильную конструкцию, хотя код компилируется отлично ... – mareckmareck

0

К сожалению, там не так много можно сделать. Либо игнорируйте предупреждения, либо добавьте строку предупреждения. Возможно, что intellij имеет настройку, которая позволит вам отключать предупреждения, или вы можете иметь предупреждения, напечатанные в окне, на которое вы не обращаете внимания, но ни одно из них не является отличным решением, так как эти параметры устранят другие соответствующие предупреждения, которые вы можете захотеть видеть.