Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > de.comp.lang.java > #12982

Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle

From Patrick Roemer <sangamon@netcologne.de>
Newsgroups de.comp.lang.java
Subject Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle
Date 2016-07-09 00:01 +0200
Organization news.netcologne.de
Message-ID <nlp7qu$j5a$1@newsreader4.netcologne.de> (permalink)
References <du7ob7Fecu7U1@mid.individual.net> <du9qajFt4ctU1@mid.individual.net>

Show all headers | View raw


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

Back to de.comp.lang.java | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-07 21:19 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Peter <peter@localhost.com> - 2016-07-07 22:37 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Michael Paap <feunews@mpaap.de> - 2016-07-07 23:21 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 14:09 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 22:10 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-09 00:17 +0200
        Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-18 00:33 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-18 01:01 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-19 10:58 +0200
            Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-21 00:07 +0200
          Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-19 14:09 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-08 00:28 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 14:13 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-08 16:05 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 22:35 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Patrick Roemer <sangamon@netcologne.de> - 2016-07-09 00:01 +0200
      Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-11 00:40 +0200
        Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 23:25 +0200
    Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-15 00:12 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle Wanja Gayk <brixomatic@yahoo.com> - 2016-07-08 21:57 +0200
  Re: Unit-Tests von Einheiten ohne öffentliche Leseschnittstelle "Christian H. Kuhn" <qno-news@qno.de> - 2016-07-11 01:13 +0200

csiph-web