Ok, also hier der relevante Teil aus der parent pom (ist ein multi-module Projekt):
[XML]
…
org.codehaus.mojo
cobertura-maven-plugin
2.6
…
org.codehaus.mojo
cobertura-maven-plugin
2.6
true
com/unittestcloud/**/R.class
clean
</build>
…
[/XML]
Ich kann da eintragen was ich möchte, nichts wird exkludiert. Das ist ein Problem wo man einiges bei Google findet, aber eine funktionierende Lösung habe ich noch nicht gefunden.
[QUOTE=Timothy_Truckle;70801]Hast Du schon mal versucht “test” als execution/goal anzugeben? Ich denke, beim “clean” wird die Konfiguration nicht viel nützen…
bye
TT[/QUOTE]
Da verstehst du was falsch, diese Konfiguration bindet das cobertura:clean Goal an das Maven clean goal. Das steht auch so in der Doku von Cobertura, s. Link in erstem Post.
Das Erzeugen des Reports muss man mit cobertura:cobertura aufrufen.
[quote=deetee]Das Erzeugen des Reports muss man mit cobertura:cobertura aufrufen.[/quote]Vielleicht bin ich ja blind, aber diese Configuration sehe ich in Deinem Auszug nicht…
Den Aufruf schreibt man ja auch nicht in die pom.xml. Man fügt die Config in die pom.xml ein und ruft den Code Coverage Report anschließend mit mvn cobertura:cobertura auf. Das Ergebnis wird in target/site/cobertura gespeichert.
[quote=deetee]Den Aufruf schreibt man ja auch nicht in die pom.xml[/quote]Nach meinem Verständnis kann die Konfiguration nur für das goal gelten, für dass sie in der pom konfiguriert ist. Demnach hast Du dein cobertura so konfiguriert, dass es den Report für die Klasse R nicht löscht…
Also damit du dich nicht weiter daran störst (denn du interpretierst das falsch) habe ich diese executions Konfiguration mal rausgenommen. Es ändert nichts am Ergebnis.
Die Reports habe ich schon manuell gelöscht oder durch mvn clean, etc. Sie werden jedesmal neu generiert, nur leider mit den Klassen, die eigentlich exkludiert sein sollten.
Jetzt aber mal blöd gefragt. Klassen aus einem Report über Code Coverage ist dann ja nichts anderes als Manipulation des Ergebnisses. Und da ist für mich ehrlich gesagt der Knackpunkt weshalb das was du gerade machst eigentlich total sinnlos ist. Der Sinn und Zweck von solchen Metriken ist NICHT dass man 100% erreicht. Von daher wäre es (mir persönlich) relativ egal ob in meinem Report 63% oder 69% steht. Diese Reports dienen doch eher dazu dir zu zeigen wo potentielle Schwachstellen liegen könnten. Und deshalb finde ich es immer schlecht, wenn man aktiv Dinge ausschließen möchte. Warum sollte das im Report nicht auftauchen? Sie sind ja schließlich auch nicht (von dir) getestet.
@Gonzo
Das macht durchaus Sinn was ich da machen möchte, da die Android R Klasse mich im Code Coverage Report wirklich null interessiert und das Ergebnis auch null verfälscht wird möchte ich sie raushaben. Und es gibt je nach Projekt mehrere R Klassen, je App und APKLib eine R Klasse. Es handelt sich also nicht nur um eine einzige Klasse.
Verfälscht? Es ist doch de facto so, dass du für diese Klassen keine Code Coverage hast. Nur weil das (berechtigterweise) uninteressant ist muss das doch nicht raus aus dem Report. Und wie gesagt, da wären wie bei dem Irrglauben: Das Ziel darf nicht sein 100% Code Coverage erreichen zu wollen. Das bringt eben rein garnichts. Nehmen wir mal an du hast jetzt bereits 3h damit verbracht eine Lösung für dein Problem zu finden. Wäre es nicht viel effektiver (fürs Produkt) gewesen, wenn du diese 3h damit verbracht hättest in den Report zu schauen um zu sehen wo potentielle Schwächen sind?
Das ist das was ich meine. Die Metrik sollte für dich arbeiten, nicht du für die Metrik.
@Gonzo
Keine Ahnung wie du darauf kommst, dass ich 100% anstrebe. Das ist nicht so. Die Klasse gehört nicht zu meinen Sourcen und deshalb soll sie nicht im Code Coverage Report auftauchen. Ich möchte damit die Übersicht steigern und nicht auf 100% kommen.
Es ist absolut legitim was ich mache, genau für diesen Fall gibt es ja diese Funktionalität in Code Coverage Tools.
Die R-Klasse in Android ist ja eine dynamisch generierte Klasse, gehört also durchaus zu deinen Sourcen.
Legitim ist vieles, aber nur weil eine Funktion existiert muss sie nicht sinnvoll sein. Alles was ich sagen möchte ist ja, dass man sich über den Nutzen klar sein sollte. Ich würde es wie gesagt nicht machen, wofür auch? Übersichtlicher? Naja. Und ich bin eben der Meinung, dass diese Klasse auch auftauchen darf, weil sie ja de facto existiert und ungetestet ist. Auch wenn du sie nicht produzierst und ein Test nicht notwendig ist. Aber selbstverständlich darfst du das handhaben wie du magst, ich wollte nur einen Denkanstoß geben.
Stell dir vor du hast eine große Anzahl solcher Klassen, würdest du sie dann immernoch im Code Coverage Report drinhaben wollen?
Man nimmt aus dem Code Coverage Report alles raus was bei der Analyse irrelevant ist. Einfache Grundregel für eigentlich alle Reports. Das vermeidet Missverständnisse bei der Analyse und steigert die Übersicht. Ich merke zwar, dass du dir durchaus deine Gedanken gemacht hast zu dem Thema, aber offensichtlich noch nicht genug Code Coverage analyse betrieben hast…vor allem nicht von Code, den du nicht kennst, denn gerade in solchen Fällen wirst du eine bessere Übersicht zu schätzen wissen.
[quote=deetee]Man nimmt aus dem Code Coverage Report alles raus was bei der Analyse irrelevant ist.[/quote]Das Zeug würde ich dann aber auch in einem eigenen Projekt zusammenfassen, welches ich bei der Analyse ignorieren kann, selbst wenn dieses nur eine einzige Klasse enthielte.
Ich habe nur die R Klasse ausgeschlossen, aber leider nicht deren inneren Klassen. Wenn ich diese exkludiere, dann verschwindet die R Klasse aus dem Report:
[QUOTE=deetee]Stell dir vor du hast eine große Anzahl solcher Klassen, würdest du sie dann immernoch im Code Coverage Report drinhaben wollen?
Man nimmt aus dem Code Coverage Report alles raus was bei der Analyse irrelevant ist. Einfache Grundregel für eigentlich alle Reports. Das vermeidet Missverständnisse bei der Analyse und steigert die Übersicht. Ich merke zwar, dass du dir durchaus deine Gedanken gemacht hast zu dem Thema, aber offensichtlich noch nicht genug Code Coverage analyse betrieben hast…vor allem nicht von Code, den du nicht kennst, denn gerade in solchen Fällen wirst du eine bessere Übersicht zu schätzen wissen.[/QUOTE]
Ob es irrelevant ist? Darüber lässt sich bestimmt streiten. Es ist eben eine Klasse in deinem Projekt.
Und was ich meine ist ja der Kompromiss zwischen Aufwand und Nutzen. Ich sehe jetzt nicht, dass der Nutzen so groß wäre, wenn man einzeln bestimmte Klassen ausklammert. Wir reden hier ja nicht von Komponenten wie zum Beispiel modelbasierten Editoren. Sowas würde ich, wie Timothy_Truckle auch sagt, einfach in ein separates Projekt lagern. Dafür investierst du aber verhältnismäßig viel Zeit, zumindest macht das für mich den Eindruck.
Die Standpunkte sind ja jetzt klar, also belasse ich es dann hierbei. Du sollst ja auch noch eine Lösung für das Problem finden.
[QUOTE=Gonzo]Ob es irrelevant ist? Darüber lässt sich bestimmt streiten. Es ist eben eine Klasse in deinem Projekt.
Und was ich meine ist ja der Kompromiss zwischen Aufwand und Nutzen. Ich sehe jetzt nicht, dass der Nutzen so groß wäre, wenn man einzeln bestimmte Klassen ausklammert. Wir reden hier ja nicht von Komponenten wie zum Beispiel modelbasierten Editoren. Sowas würde ich, wie Timothy_Truckle auch sagt, einfach in ein separates Projekt lagern. Dafür investierst du aber verhältnismäßig viel Zeit, zumindest macht das für mich den Eindruck.
Die Standpunkte sind ja jetzt klar, also belasse ich es dann hierbei. Du sollst ja auch noch eine Lösung für das Problem finden.[/QUOTE]
Was soll denn an einer Klasse wie der R Klasse relevant sein für den Report? Es gibt da genügend Einzelfälle in fast jedem Projekt, übrigens schließe ich auch die BuildConfig.class von Android aus. Interessiert genauso wenig. So summiert sich das.
Wieviel Zeit ich in etwas investiere musst du schon jedem selbst überlassen. Ich habe das Problem und die Lösung zumindest verstanden und ein zweites mal passiert mir das nicht mehr. Eure Standpunkte sind nunmal nicht optimal, aber ihr scheint einfach zu wenig mit dem Thema zutun zu haben, dass es für euch einfach nicht wichtig genug ist.
@kama
Werde ich mal testen, allerdings ist es wesentlich wichtiger, dass der Report weiterhin unabhängig und einzeln erstellt werden kann. Müsste aber dann ja immernoch funktionieren.
