Path: csiph.com!news.swapon.de!newsreader4.netcologne.de!news.netcologne.de!.POSTED.xdsl-89-0-215-40.netcologne.de!not-for-mail From: Patrick Roemer Newsgroups: de.comp.lang.java Subject: =?UTF-8?Q?Re:_Unit-Tests_von_Einheiten_ohne_=c3=b6ffentliche_Lesesc?= =?UTF-8?Q?hnittstelle?= Date: Sat, 9 Jul 2016 00:01:00 +0200 Organization: news.netcologne.de Distribution: world Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 8 Jul 2016 22:01:02 +0000 (UTC) Injection-Info: newsreader4.netcologne.de; posting-host="xdsl-89-0-215-40.netcologne.de:89.0.215.40"; logging-data="19626"; mail-complaints-to="abuse@netcologne.de" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 X-Mozilla-News-Host: news://news.netcologne.de In-Reply-To: Xref: csiph.com de.comp.lang.java:12982 Responding to Christian H. Kuhn: > switch (poss) { > case A: > System.out.println("Fall A"); > break; > case B: > System.out.println("Fall B"); > break; > } [...] > Ein default in der Switch-Anweisung wäre unerreichbarer Code; andere > Möglichkeiten als A und B können nicht vorkommen. Trotzdem wäre ein zusätzlicher default-Branch legal und damit eben ein weiterer Codepfad. > Insbesondere kann poss > nicht null sein, das wird durch Konstruktor und setPoss verhindert. null ist nicht das Problem - auch, weil das eine NPE bei Auswertung des "poss" triggern müsste, bevor es überhaupt in die Verzweigung ginge. > Ohne > Default behauptet JaCoCo aber, dass nur 2 von 3 Branches abgedeckt sind. Im Bytecode stehen auch drei Branches - javac generiert einen synthetischen default-Branch. Und der lässt sich von einem expliziten no-op Default-Branch im Sourcecode nicht unterscheiden. (Und ggfs. setzen andere Compiler dieses Konstrukt anders um.) Es ist also auch etwas schwierig für JaCoCo, das "richtig" zu interpretieren. Wahrscheinlich gibt es andere Coverage-Tools, die entsprechende Heuristiken eingebaut haben ("bei einem switch über das #ordinal() eines Enum, ignoriere den default branch, falls alle Werte des Enum bereits abgedeckt sind und Saturn gerade im dritten Haus steht"), aber die stolpern dann wahrscheinlich über die Bytecode-Umsetzung von String-Switches oder etwas ganz anderes. Ein Tool, das unter allen Umständen weder false positives noch false negatives liefert, wird man wohl kaum finden - spätestens, wenn Du sowas erwartest, wie bei dem null-Argument oben ("Es gibt aber doch gar keinen Codepfad, auf dem ein mutable field in Zustand X versetzt werden kann!"). > Sourcen ändern, um bei > gleicher Funktionalität Tests zu erfüllen, ist wohl kein guter Gedanke. Unter Umständen schon, das nennt sich Refactoring und Test-Driven-Design. :) Hier geht es aber nur darum, ein automatisiertes Tool glücklich zu machen, das den Codefluss nicht versteht. Und Code schlechter zu machen, damit das Tool ihn für gut hält, ist wirklich nicht so prima. (Das gilt genauso für PMD, FindBugs, etc., nur, dass in deren Domäne Ausnahmen besser konfigurierbar sind.) > Den Branch-Schwellenwert, der für einen grünen Build erreicht werden > muss, abzusenken kann auch keine Lösung sein, denn der erträgliche Wert > hängt zu sehr von der Anzahl der switch- zu sonstigen Verzweigungen ab. Was soll denn ein solcher Schwellenwert bringen? Bei 80% Abdeckung ist mein Code ok, bei 79.9% Mist? Boiling Frogs... IMHO bringt Coverage-Reporting nur was, wenn man sich die Ergebnisse wiederholt im Laufe der Zeit ansieht, um Trends zu erkennen, und jeweils in die konkret auffälligen Stellen reindrillt, um Kategorien von Schwachstellen zu identifizieren. > Bleibt ein anderes Tool. Oder die Erkenntnis, dass die Dinger einfach nicht perfekt sein können. Ich fand Emma/JaCoCo bisher durchaus brauchbar. Kann gut sein, dass andere Tools relativ dazu besser sind (entsprechendes Feedback dazu hier würde ich wohl zum Anlass nehmen, mir die auch mal anzuschauen), aber Wunderdinge würde ich von keinem erwarten. Viele Grüße, Patrick