Mockito вызывает ложные срабатывания в Coverity?

Мы используем Coverity для выявления потенциальных недостатков безопасности и качества в нашем Java-коде. В одном из наших модульных тестов у нас есть тест, который включает код подключения к базе данных:

Connection connection = mock(Connection.class);
Statement statement = mock(Statement.class);
when(connection.createStatement()).thenReturn(statement);

Coverity жалуется на потенциальную утечку ресурсов:

CID 21920: утечка ресурсов (RESOURCE_LEAK) 4. leaked_resource: не удалось сохранить или закрыть ресурс, созданный с помощью connection.createStatement ()

Мое понимание того, как работает Mockito, состоит в том, что connection.getStatement() на самом деле никогда не вызывается, и поэтому не создается никаких операторов, которые нужно закрыть позже. (Это отличается от типичного случая в базах данных, где необходимо закрыть соединение JDBC.)

Я правильно понимаю? Справедливо ли сказать, что это ложное сообщение от Coverity, вызванное нетипичным поведением getConnection() в контексте насмешек? Если нет, пожалуйста, поправьте меня.


jdbc mockito coverity resource-leak
person kc2001    schedule 24.03.2020    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Я бы сказал, что ваше понимание не совсем правильное.

В вашем коде connection.createStatement() действительно вызывается, но он не вызывается в «реальном» соединении, которое создаст ресурс где-то в базе данных. Мок-реализация Connection, которую Mockito создает, просто отслеживает, что метод был вызван, и возвращает null. Позже, когда вызывается метод thenReturn(), Mockito может связать вызов с createStatement() со значением, переданным в thenReturn(), чтобы макет Connection мог вернуть макет Statement, когда для него вызывается метод createStatement().

В конечном счете, это ложный положительный отчет от Coverity: здесь нет проблемы с утечкой ресурсов. Однако возникает вопрос о ценности запуска такого сканера, как Coverity, на тестовом коде. В частности, я не уверен, как у вас может быть недостаток безопасности в тестовом коде, учитывая, что он не интерактивен и не является чем-то, что вы либо отправляете клиентам, либо загружаете где-нибудь на сервер.

person Luke Woodward    schedule 24.03.2020
comment
Для меня все это имеет смысл. Спасибо. И вы правы в том, что это не считается недостатком, если оно не доставляется клиентам. Coverity позволяет задавать подобные обоснования, чтобы исключить ложные срабатывания. OTOH, я читал о том, как утечки ресурсов могут вызывать возможные сбои при попытке запустить тестовые наборы, и я хотел подтвердить свои мысли о том, что на самом деле это не утечка ресурсов. - person kc2001; 25.03.2020