Knobelaufgabe ( Sommer 2022 ) - Unit Test Coverage

Re: Knobelaufgabe ( Sommer 2022 ) - Unit Test Coverage

hi.

Ich komm mit vier Aufrufvarianten auf eine Abdeckung von 80%/100%/100%. Nur die Klasse "LCL_TEST" berücksichtigt und den Abschnitt "START-OF-SELECTION:00" nicht mitgezählt.
(Details siehe PM)

lg ADT

Re: Knobelaufgabe ( Sommer 2022 ) - Unit Test Coverage

Zur Info für andere Teilnehmer, bevor diese an der 100%-Hürde verzweifeln:
100% Zweigabdeckung wird nicht möglich sein. Die maximale Zweigabdeckung der Klasse lcl_test dürfte 90% sein.

Re: Knobelaufgabe ( Sommer 2022 ) - Unit Test Coverage

Moin allerseits,
ca 1,5 Wochen sind vergangen und es haben sich gerade mal 2 Wettbewerber gefunden. Liegt's daran, dass Ferienzeit ist, ist das Thema zu exotisch oder war die Aufgabe zu leicht/schwer? Ist auch egal - ich erkläre jetzt einfach was das Ziel dieser Knobelaufgabe war.
Ich glaube der einfachste Weg ist kurz zu erklären was gemacht wird, und dann baue ich sukzessive eine maximale Lösung auf mit Erklärungen warum was gemacht wird.

Zunächst einmal hat das zu prüfende Programm offensichtlich 2 Bereiche. Den (implizt vorhandenen) Zeitpunkt START-OF-SELECTION und die Klasse lcl_coverage_test. Die "Probanden" habe alle nur die Coverage der Klasse getestet, aber ein einfaches sorgt dafür, dass das Rahmenprogramm als vollständig geprüft gilt, einfach weil der Zeitpunkt START-OF-SELECTION erreicht wird und dort einfach nichts passiert.

Aber der interessante Teil ist ja schließlich das Testen der Klasse und alle Prozentzahlen, die ich ab hier liefere gelten für nur für diese Klasse und nicht für das gesamte Programm.
Wir tasten uns jetzt sukzessive an die optimale Lösung heran.
Prozedurabdeckung/Procedure coverage
Die Demolösung hat einen ersten Ansatz gegeben welches die Klasse mit ein paar Daten erzeugt und dann die beiden Methoden aufruft. Da hiermit alle in der Klasse vorhandenen Methoden aufgerufen wurden erreichen wir schon eine Prozedurabdeckung von 100%. Das war einfach.

Anweisungsabdeckung/Statement coverage
Allerdings hat dieser simple Ansatz bisher erst 93%,67%,67% Anweisungsabeckung für Constructor, get_log_sum und get_odd_max. Ein Doppelklick auf die jeweilige Methode offenbart, welche Befehle bisher nicht erreicht wurden.

• Constructor - es fehlt das "RAISE EXCEPTION" in Zeile 38
• GET_LOG_SUM - Es fehlt das CONTINUE auf Zeile 87 im Catch-Block
• GET_ODD_MAX : Es fehlt das RETURN in Zeile 70 und der IF-Block in Zeile 74

Die RAISE-Bedingung im Konstruktor wird erreicht, wenn iv_count < 0 ist, somit fügen wir den Unit tests folgende Zeilen hinzu: Für die Methode GeT_LOG_SUM muss irgendwas im TRY-CATCH Block schief gehen, damit wir in den CATCH-Block gelangen. Und wenn ich arithmethische Anweisungen sehe fallen mir immer "Teilen durch Null" und "Überlaufprobleme" ein. Wir haben hier ein "geteilt" in der Anweisung rv_sum = rv_sum + 1 / <lv_number>. Wir müssen also dafür sorgen, dass in der Zahlenliste eine 0 auftauchte. Das ist am einfachsten machbar, indem wir lv_max im Konstruktor auf 0 setzen -dann sind alle Zahlen der Liste = 0. Alternativ können wir auch die Anzahl der Einträge viel größer machen als die Anzahl die möglichen Listeinträge. Dann wird es sehr wahrscheinlich, dass einer der Einträge = 0 ist und wenn man ein wenig mit dem Seed rumspielt sollte man auch so einen "ehrlicheren" Testfall erzeugen. Aber wir wählen den dreisten Ansatzu und fügen dem Unit test folgenden Aufruf hinzu: Das "RETURN" in der Methode GET_ODD_SUM wird erreicht, wenn die Tabelle MT_NUMBERS leer ist oder mv_range_is_filled abap_false. Wenn man sich den Konstruktor genauer anschaut wird man feststellen, dass letztere Bedingung nie erfüllt werden wird, somit muss wohl die 1. Bedingung erfüllt werden: Die Tabelle mt_numbers muss leer sein --> iv_count = 0 welches zu folgendem Aufruf führt Jetzt muss "nur" noch irgendwie der Tabellenkörper des LOOPS in der Methode GET_ODD_SUM erreicht werden. D.h, die WHERE Bedingung "WHERE table_line IN mt_r_odd" muss erfüllt sein. Und hier ist mir ein Fehler unterlaufen, da die Range mt_r_odd immer nur aus einer einzigen Zeile besteht. Gedacht war eigentlich, dass sie alle ungeraden Zahlen aufnimmt, aber ein Flüchtgkeitsfehler im Constructor, der diese Range erstellt, wo ich vergessen habe, dass SORT Zahlenfelder ignoriert wenn diese nicht explizit angegeben werden führt dazu, dass mehr oder minder zufällig irgend eine der Zeilen der Tabelle mt_sort übrig bleibt. Wie dem auch sei - auch hier kann man mit einem einfachen Ansatz weiterkommen. Wir brauchen eine ungerade Zahl in der Liste, welche mit einer der ungeraden Zahlen der Range übereinstimmt. Da im Konstruktor explizit die Zahl 1 in die Range eingefügt wird können wir im Konstruktor mit dem Parameter iv_max = 1 dafür sorgen, dass wir nur die 0 und 1 in der Zahlenliste haben. Dass die Zahl 1 auch tatsächlich in der Zahlenliste ist bewerkstelligen wir, indem wir count hoch ansetzen ( z.B. 10000 ). Dann haben wir 10000 Zahlen in der Liste von denen ~ die Hälfte 0 und die andere Hälfte 1 ist. Die Wahrscheinlichkeit, dass alles Nullen sind, ist hinreichend gering. --> Der folgende Unit-Test sorgt für Abhilfe Zweigabdeckung/ Branch coverage
Die ganzen obigen Tests haben auch die Zweigabdeckung schon recht weit nach oben getrieben und wir haben aktuell 89%,75%,100% Zweigabeckung für Constructor, get_log_sum und get_odd_max
Die Frage ist nur: Wo zum Geier sind die fehlenden Prozente im Constructor und get_log_sum, wo doch alle Programmzeilen durchlaufen wurden?

Und hier haben wir schon die erste Merkwürdigkeit: In der Methode GET_LOG_SUM ist keine Bedingung, welche durch einen fehlenden Zweig nicht erfasst wurde, aber die Zweigabdeckung behauptet, dass nur 3 von 4 Zweigen durchlaufen wurden. Hier habe ich nach längerer Diskussion mit Enno begriffen, dass ein LOOP / ENDLOOP zwei Zweige darstellt. Einer, wenn der LOOP-Körper erreicht wird, der andere wenn nicht. Wenn also der LOOP gar nicht durchlaufen wird, wird der noch fehlende Zweig abgehandelt. Da hier keine Bedingung angegeben ist, muss dafür die Tabelle, über die die Schleife läuft leer sein --> count = 0 im Konstruktor führt zu folgendem Unittest, mit dem die Zweigabdeckung auch dieser Methode auf 100% geht:
Bleibt noch der Konstruktor: Wo ist der fehlende Zweig? Das Problem ist die letzte IF-Bedingung in Zeile 54. das IF lines( mt_r_odd ) > 0 ist immer erfüllt, weil wir in Zeile 42 eine Zeile in diese Tabelle einfügen. Und die Zweigabdeckung zählt jeden Ausgang einer Bedingung und ob dieser in mind. einem der Unittests erfüllt wurde. Durch die Programmkonstellation im Konstruktor kann das hier nie erfüllt werden, so dass die Zweigabdeckung des Konrtuktors nicht höher werden kann. Wenn man jetzt behauptet, dass man in diesem Fall ja die Bedingung in Zeile 54 rauswerfen kann , weil die IF-Bedingung de facto immer TRUE ist. Wenn man die Zeilen 54 und 56 auskommentiert, kommt man auf die 100% Zweigabdeckung, aber das Ändern des Originalcodes war ja explizit ausgeschlossen worden.


Was bedeutet das für Unitests und den eigenen Programmierstil: Anweisungskombinationen wie führen dazu dass der Tabellenkörper immer durchlaufen wird, was zu einer reduzierten Codeabdeckung führt. Desweiteren führen auch Anweisungen wie if 1 = 0 oder if 1 = 1. ( z.B. für Cross-Reference ) dazu, dass in diese Bedingung entweder immer Wahr oder immer Falsch ist, so dass nie beide Zweige durchlaufen werden können. Und beides sind Techniken, die man hier und da ob der besseren Wart/Lesbarkeit des Codes durchaus einfügt.
Und schlussendlich ist es extrem schwer in einem etwas längeren Coding die Stellen zu finden, wo ein Zweig nicht durchlaufen wurde. Denn wer weiß schon, was SAP als Zweig zählt.
Für die Fleißbienen hier im Forum: Probiert doch mal aus, ob "DELETE ADJACENT DUPLICATES FROM..." oder "DELETE itab WHERE" so wie LOOP implizit einen Branch aufmachen?