Normalmente non uso la reflection direttamente durante la programmazione in Java. Ma io uso API e framework che si basano internamente su riflessioni o annotazioni per fornire punti di personalizzazione.
Molti framework utilizzano annotazioni per impostare l'iniezione di dipendenza o eseguire una sorta di cablaggio logico automatico per conto dell'utente.
Ciò comporta un sacco di accessi al campo, al metodo e al costruttore che l'analizzatore di codice statico non può seguire, causando molti falsi positivi (non solo avvertimenti "metodo / campo non utilizzato"). La mia unica opzione realistica per continuare a sopprimere questi avvertimenti o ci sono altre cose che posso fare per aiutare l'analizzatore a capire meglio i veri punti di ingresso delle mie classi?
Ho sentito alcune persone discutere di utilizzare il codice di test per questo scopo.
In molti casi, I potrebbe probabilmente scrivere casi di test rilevanti che fanno scomparire gli avvertimenti, ma sono preoccupato per il numero piuttosto elevato di casi in cui ciò implicherebbe la verifica dei dettagli di implementazione invece di comportamento osservabile. Questo codice ha già una copertura adeguata e non voglio scrivere test che mi pentirò di scrivere ogni volta che eseguo la manutenzione. Ma se il test di whitebox è davvero a volte l'alternativa "migliore", ci sono modi per ridurre al minimo gli aspetti negativi? La fragilità e la perdita di implementazione sono le mie preoccupazioni principali.