Nicht aufgerufene Methoden in Eclipse ermitteln

[Sniper]

Hallo liebe Community,

ich habe ein großes Projekt in Eclipse entwickelt. Nun möchte eine Refactoring durchführen. Meine Frage ist, wie ich nicht aufgerufene Methoden in Eclipse ermitteln kann? Gibt es ein Tool dafür?

Gruss,
Sniper

 

[maki]

Ich nutze Cobertura, um die Coverage vo Unittests zu ermitteln.
EMMA soll auch gut sein.

 

[Sniper]

Hallo,
vielen Dank für deine Antwort. Gibt es in Eclipse kein Tool dafür?

Gruss,
Sniper

 

[maki]

Es gibt Maven2 Plugins für beide, ob es eines für Eclipse gibt weiss ich nicht.

 

[kama]

Hallo,

schau Dir das mal an:

http://www.ucdetector.org/

MfG
Karl Heinz Marbaise

 

[Guest]

http://www.eclemma.org
Funktioniert auch einwandfrei mit Ganymede.

 

[Sniper]

vielen Dank für die Antworten. Es sind Tools, die ich benötigt habe.

Gruss,
Sniper

 

[Guest]

http://www.eclemma.org
Funktioniert auch einwandfrei mit Ganymede.

Das ist falsch: Mit Eclemma findet man keinen unnötigen Code.
Richtig ist: Man kann Methoden finden, die nicht durch die JUnit Tests aufgerufen werden. Das ist aber was anderes.

http://www.ucdetector.org/ dagegen findet Code, der nicht referenziert wird.

 

[maki]

http://www.ucdetector.org/ dagegen findet Code, der nicht referenziert wird.

Code der nicht referenziert wird ist nicht unbedingt ungenutzt, man denke an Reflection und DI.

 

[ARadauer]

ja klar steht aber auch auf der homepage

Limitations
The problems found by UCDetector, are only suggestions.
Before deleting or changing your code you should really know what you are doing!
If UCDetector tells you, that there are no references of your class, method or field your code still may be used by:
Reflection
Declaration in no java files like property files, xml files...
Third party code, which is using your code
Jars in your workspace
To be continued...
Change visibility to private or protected may have side effects to inheritance, reflection...

 

[maki]

Das macht das Ding in größeren Projekten(und wo sonst sollte man nach Dead Code suchen???) nutzlos

 

[SlaterB]

nutzlos ist übertrieben,
normalerweise weiß man doch etwas Bescheid, auf welche Teile der Applikation über DI oder Reflection zugriffen werden,
idealerweise sind das ja wohldefinierte vorgeschaltete Klassen/ haben besondere Namen/ packages oder so,
z.B. die Menge aller Hibernate-Beans,

während andere ganz deutlich eine andere Aufgabe/ einen anderen Zugriff haben,
etwa die Logik/ Berechnungsklassen

 

[Murray]

Und wie sollte man auch anders nach unbenutztem Code suchen können? Wenn man davon ausgehen muss, dass es noch (Fremd-)Code gibt, den man bei der Analyse nicht berücksichtigen kann oder wenn man damit rechnen muss, dass per Reflection auf den Code zugegriffen wird, dann kann es da wohl keine sichere Lösung geben.

 

[maki]

Und wie sollte man auch anders nach unbenutztem Code suchen können? Wenn man davon ausgehen muss, dass es noch (Fremd-)Code gibt, den man bei der Analyse nicht berücksichtigen kann oder wenn man damit rechnen muss, dass per Reflection auf den Code zugegriffen wird, dann kann es da wohl keine sichere Lösung geben.

Man nimmt eben EMMA oder Cobertura, um die Coverage von Tests zu ermitteln, eben dass was wirklich aufgerufen/durchlaufen wird.
Es soll Wege geben diese Tools auf nicht-Tests laufen zu lassen, waren mir aber zu Komplex.

 

[Murray]

Man nimmt eben EMMA oder Cobertura, um die Coverage von Tests zu ermitteln, eben dass was wirklich aufgerufen/durchlaufen wird.
Es soll Wege geben diese Tools auf nicht-Tests laufen zu lassen, waren mir aber zu Komplex.

wie auch immer diese Tools funktionieren: entweder arbeiten sie durch Analyse der Sourcen, oder sie protokollieren irgendwie mit, welche Code-Teile in einem echten Programmlauf aufgerufen werden. Ersteres funktioniert nicht, wo andere Referenzen als direkte Aufrufe verwendet werden (Reflection) oder wo Fremdcode nicht analysiert werden kann, letzteres setzt voraus, dass der Programmablauf, der protokolliert wird, eben alles umfasst, was in der Praxis vorkommt - und um das zu garantieren, müsste man also schon wissen, was der "dead code" ist.

 

[maki]

Mit EMMA sollte es die Möglichkeit geben, Code zu instrumewntieren und diesen dann auf einen Testserver zum laufen zu bringen, nachdem man alle möglichen Anwendungsfälle durchgespielt hat, sollte man sehen was gar nicht mehr benutzt wird.

Soweit meine Theorie, war mir dann aber zu umständlich umzusetzen, speziell der Teil "nachdem man alle möglichen Anwendungsfälle durchgespielt hat" hört sich nicht so prickelnd an.

 

[Gast]

Clover: Coverage von Unittests

http://www.atlassian.com/software/clover

 

[spj]

ICH habe ein großes Projekt in Eclipse entwickelt.

Für das hier beschriebene Szenario scheint mir UCDetector das Richtige zu sein, da der Programmierer seinen Code kennt. Das heisst, er weiss wahrscheinlich:
- welcher Code per Reflection aufgerufen wird
- welcher API Code von "ausserhalb" aufgerufen wird

Zum Thema Reflection bietet UCDetector immerhin:
- Volltextsuche nach voll qualifizierten Klassennamen
- Filter für Klassen/Methoden/Feld Namen
- Filter für Bean Methoden
Das löst das Reflection Problem natürlich nicht vollständig.

Ein Schwachpunkt von EMMA ist, dass Testcode vorhanden sein MUSS, was nicht immer gegeben ist.

Mit UCDetector kann man sofort loslegen.

 

[Tobias]

Ich könnte mir eine Lösung mit AspectJ vorstellen ... Hab's allerdings nicht ausprobiert. Sowas wie:

aspect CodeUnusedTest {
    declare error : !(execution(*..*.*(..)) : "Methode wird nicht benutzt";
}

mpG
Tobias