Suppression d'un avertissement de déréférencement nul dans l'analyse statique provenant des implémentations de stub dans les tests

Question

J'ai rencontré un motif dans les résultats faux positifs de Coverity Scan. J'ai une interface I, et deux implémentations, IImpl et FakeI

interface I { 
    String f(); 
} 

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

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

Compte tenu de ce code, si je fais alors le suivant

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

Je reçois un avertissement de déréférence NULL, car la suite de i.f() pourrait peut-être être nul à partir de FakeI. Le FakeI est implémenté dans le code de test, donc mon code de production ne le voit même pas. Mais Coverity ne le sait pas.

Quelles sont les solutions possibles? Je pensais soit supprimer complètement le code de test de l'analyse, ou revoir mes faux et m'assurer qu'ils ne renvoient pas de null. Y at-il une fonctionnalité de couverture qui pourrait aider à gérer cela?

Answer 1

Les analyseurs statiques en général ne bénéficient pas d'inclure le code de test à l'analyse. Ceci est en contraste avec l'analyse dynamique, où les tests jouent un rôle crucial. Ils sont ce qui est en cours d'exécution, de sorte qu'il y a quelque chose à analyser. Étant donné que les tests représentent une utilisation simplifiée (plus courte et autonome) des API, il est plus facile d'analyser les rapports générés à partir des tests que ceux générés par les binaires actuels.

Il y a quelques avantages à inclure le code de test dans l'analyse statique.

1. Il peut y avoir des bugs dans les tests, que l'analyseur peut aider à trouver et à résoudre.

Il existe cependant des inconvénients. Surtout ce que je demandais ici.

J'essaie maintenant de retirer les tests de la portée de l'analyse, ce qui semble être ce que recommande la documentation de Coverity Scan. Leur commande maven build est mvn compile.