Wie viel Unit-Test darf es denn sein?
4 Beiträge
•
Seite 1 von 1
4 Beiträge
Seite 1 von 1
Beitrag
von der_neuling (ForumUser / 89 / 18 /
3
)
»
Grüßt euch werte Mitforisten,
heute stelle ich mir wieder einmal die Frage wie viel Unit-Test es denn eigentlich sein sollte, um ein angemessenes Maß zwischen der Robustheit des Codes und der Wirtschaftlichkeit herzustellen.
Dabei beziehe ich mich nicht auf die jeweilige "Geschäftslogik", sondern auf Klassiker wie etwa JOINS oder simple SELECT Anweisungen.
Gegeben sei folgendes Szenario:
In einer Kundentabelle werden Preise fortgeschrieben, es soll nun immer der jeweils höchste innerhalb des Betrachtungszeitraums zurückgegeben werden.
Nun könnte man ja diverse Testfälle erzeugen, wenn man es genau nehmen will, also z.B. alle Randbedingungen der Datumsangabe:
Wie handhabt ihr das ganze? So detailliert wie mein Vorschlag oder eher die kompaktere Variante:
Ich freue mich auf eure Anregungen/Antworten 😇
heute stelle ich mir wieder einmal die Frage wie viel Unit-Test es denn eigentlich sein sollte, um ein angemessenes Maß zwischen der Robustheit des Codes und der Wirtschaftlichkeit herzustellen.
Dabei beziehe ich mich nicht auf die jeweilige "Geschäftslogik", sondern auf Klassiker wie etwa JOINS oder simple SELECT Anweisungen.
Gegeben sei folgendes Szenario:
In einer Kundentabelle werden Preise fortgeschrieben, es soll nun immer der jeweils höchste innerhalb des Betrachtungszeitraums zurückgegeben werden.
Code: Alles auswählen.
"Highest price during Period
SELECT *
INTO TABLE rt_price_tbl
UP TO 1 ROWS
FROM /zzz/oc_price
WHERE
matnr = iv_matnr AND
werks = iv_werk AND
( bldat >= iv_date_from AND bldat <= iv_date_to )
ORDER BY BLDAT DESCENDING.
Code: Alles auswählen.
METHODS:
highest_price_wrong_plant FOR TESTING RAISING cx_static_check,
highest_price_wrong_matnr FOR TESTING RAISING cx_static_check,
date_not_in_period FOR TESTING RAISING cx_static_check,
date_from_not_within_period FOR TESTING RAISING cx_static_check, "no GE or >=
date_to_not_within_period FOR TESTING RAISING cx_static_check, "no LE or <=
not_the_highest_price_selected FOR TESTING RAISING cx_static_check,
no_order_by FOR TESTING RAISING cx_static_check,
wrong_order_by FOR TESTING RAISING cx_static_check, "Wrong Field to Sort
multiple_entries FOR TESTING RAISING cx_static_check. "more than one Entry
Code: Alles auswählen.
METHODS:
highest_price_valid FOR TESTING RAISING cx_static_check,
highest_price_no_data FOR TESTING RAISING cx_static_check,
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von black_adept (Top Expert / 4103 / 128 /
945
)
»
Als jemand, dessen Kunden i.A. nicht bereit sind für Unit-Tests zu zahlen - daher bitte mit Vorsicht genießen.
Deine SELECT-Anweisung ist doch trivial. Wenn du dafür Unit tests erstellst: Erstellst du dann auch einen Unit test für die Anweisung Datum = Sy-Datum + i, weil da ja auch theoretisch Overflow oder Underflow auftreten könnten?
Auch wenn mich Ralf nachher dafür steinigt: Wenn ich einem Kunden einen pragmatischen Ansatz vorschlagen sollte dann folgendes, unter der Annahme, dass du dein Coding üblicherweise während der Entwicklung testest, dass es in etwa so läuft wie du meinst dass es laufen sollte.
Zunächst ohne Unit Tests loslegen, es sei denn jemand hat dir tolle Vorgaben, die einem Unit-Test in etwa entsprechen, gemacht à la: "Wenn das reinkommt, dann muss das rauskommen."
Wenn dann das Ganze so halbwegs läuft wartest du auf Fehlermeldungen der Fachbereiche. Wenn du die Fehlerursache gefunden hast baust du einen ( oder mehrere ) Unit Tests, die dafür sorgen, dass diese Art von Fehler nicht mehr auftaucht. Damit sicherst du die problematischen Fälle ab und kannst trotzdem recht zügig etwas abliefern und das Progrämmsche wird im Laufe der Zeit immer abgesicherter ( es sei denn du bist so gut, dass keine Fehlermeldungen kommen - aber dann brauchst du auch keine Unittests )
Bei sehr kritischen Anwendungen solltest du diese Vorgehensweise aber nicht verwenden.
Deine SELECT-Anweisung ist doch trivial. Wenn du dafür Unit tests erstellst: Erstellst du dann auch einen Unit test für die Anweisung Datum = Sy-Datum + i, weil da ja auch theoretisch Overflow oder Underflow auftreten könnten?
Auch wenn mich Ralf nachher dafür steinigt: Wenn ich einem Kunden einen pragmatischen Ansatz vorschlagen sollte dann folgendes, unter der Annahme, dass du dein Coding üblicherweise während der Entwicklung testest, dass es in etwa so läuft wie du meinst dass es laufen sollte.
Zunächst ohne Unit Tests loslegen, es sei denn jemand hat dir tolle Vorgaben, die einem Unit-Test in etwa entsprechen, gemacht à la: "Wenn das reinkommt, dann muss das rauskommen."
Wenn dann das Ganze so halbwegs läuft wartest du auf Fehlermeldungen der Fachbereiche. Wenn du die Fehlerursache gefunden hast baust du einen ( oder mehrere ) Unit Tests, die dafür sorgen, dass diese Art von Fehler nicht mehr auftaucht. Damit sicherst du die problematischen Fälle ab und kannst trotzdem recht zügig etwas abliefern und das Progrämmsche wird im Laufe der Zeit immer abgesicherter ( es sei denn du bist so gut, dass keine Fehlermeldungen kommen - aber dann brauchst du auch keine Unittests )
Bei sehr kritischen Anwendungen solltest du diese Vorgehensweise aber nicht verwenden.
Davon abgesehen, dass Unit Tests, die auf vorhandene Daten aus der DB angewiesen sind, IMHO keine Unit Tests sind, würde ich die detaillierte Variante nehmen.
Wenn du nur zwei Fälle testest, kannst du es auch gleich sein lassen.
Der Mehrwert bei der Variante mit vielen Tests liegt darin, dass du dir überhaupt Gedanken darüber machst, was schief gehen könnte.
Für verschiedene Testfälle brauchst du verschiedene Datenkonstellationen. Das heißt, in deinem Fall müsstest du dir die zugehörigen Datensets vorher (Methode SETUP) erzeugen und beim TEARDOWN wieder löschen.
Wenn du nur zwei Fälle testest, kannst du es auch gleich sein lassen.
Der Mehrwert bei der Variante mit vielen Tests liegt darin, dass du dir überhaupt Gedanken darüber machst, was schief gehen könnte.
Für verschiedene Testfälle brauchst du verschiedene Datenkonstellationen. Das heißt, in deinem Fall müsstest du dir die zugehörigen Datensets vorher (Methode SETUP) erzeugen und beim TEARDOWN wieder löschen.
Beitrag
von der_neuling (ForumUser / 89 / 18 /
3
)
»
Das mit den Testdaten ist mir natürlich klar, für jeden oben beschriebenen Testfall kommt noch eine Setup mit der Erzeugung der Testdaten. 😊ewx hat geschrieben: ↑14.06.2022 17:29Davon abgesehen, dass Unit Tests, die auf vorhandene Daten aus der DB angewiesen sind, IMHO keine Unit Tests sind, würde ich die detaillierte Variante nehmen.
Für verschiedene Testfälle brauchst du verschiedene Datenkonstellationen. Das heißt, in deinem Fall müsstest du dir die zugehörigen Datensets vorher (Methode SETUP) erzeugen und beim TEARDOWN wieder löschen.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
805
Views
Views
7
Antw.
Antw.
2079
Views
Views
Unit Test kann nicht ausgeführt werden
von JohnLocklay » 24.08.2021 13:36 • Verfasst in ABAP Objects®
von JohnLocklay » 24.08.2021 13:36 • Verfasst in ABAP Objects®
5
Antw.
Antw.
2042
Views
Views
Knobelaufgabe ( Sommer 2022 ) - Unit Test Coverage
von black_adept » 27.07.2022 12:36 • Verfasst in SAP - Allgemeines
von black_adept » 27.07.2022 12:36 • Verfasst in SAP - Allgemeines
0
Antw.
Antw.
659
Views
Views
ABAP-Unit-Test - Absturz bei XML Serialisierung provozieren
von a-dead-trousers » 26.08.2022 12:08 • Verfasst in ABAP® Core
von a-dead-trousers » 26.08.2022 12:08 • Verfasst in ABAP® Core
2
Antw.
Antw.
2326
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.