Unterdrückung einer Null-Dereferenzierungswarnung in der statischen Analyse, die von Stub-Implementierungen in Tests stammt

Question

Ich habe ein Muster in falsch positiven Ergebnissen von Coverity Scan gefunden. Ich habe eine Schnittstelle I und zwei Implementierungen IImpl und FakeI

interface I { 
    String f(); 
} 

class IImpl { 
    String f() { 
    return "f"; 
    } 
} 

class FakeI { 
    String f() { 
    return null; 
    } 
} 

dieser Code gegeben, wenn ich folgendes

I i; 
i.f().equals(other); 

ich eine Null-Dereferenzierung Warnung erhalten dann tun, weil aufgrund der i.f() könnte möglicherweise sei das null von FakeI. Die FakeI ist in Testcode implementiert, so dass mein Produktionscode es nicht einmal sieht. Aber Coverity weiß das nicht.

Was sind die möglichen Lösungen? Ich dachte, entweder Testcode vollständig aus der Analyse zu entfernen oder meine Fälschungen erneut zu überprüfen und sicherzustellen, dass sie nicht null zurückgeben. Gibt es eine Coverity-Funktion, die dabei helfen könnte?

Answer 1

Statische Analysatoren profitieren normalerweise nicht davon, Testcode in die Analyse einzubeziehen. Dies steht im Gegensatz zur dynamischen Analyse, bei der die Tests eine entscheidende Rolle spielen. Sie sind, was ausgeführt wird, damit es etwas zu analysieren gibt. Da Tests eine vereinfachte (kürzere, in sich abgeschlossene) Verwendung der APIs darstellen, ist es einfacher, Berichte zu analysieren, die aus Tests generiert wurden, als aus tatsächlich ausgeführten Binärdateien.

Es gibt einige Vorteile, wenn Testcode in die statische Analyse eingeschlossen wird.

1. In Tests kann es Fehler geben, die der Analysator bei der Suche und Lösung helfen kann.

Es gibt jedoch Nachteile. Vor allem, worum ich hier gebeten habe.

Ich versuche jetzt, Tests aus dem Umfang der Analyse zu entfernen, die tatsächlich scheint, was Coverity Scan-Dokumentation empfiehlt. Ihr maven build Kommando ist mvn compile.