Sinn von Unit-Tests
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo Zusammen,
einer unserer Azubis hat mir heute eine frage gestellt, die ich so nicht wirklich beantworten kann.
Ich bin ehrlich, ich schreibe nicht viele Unit-Tests, geschweige denn dass ich isolierungen mache.. aber genau da hängt das problem.
Mein Azubi hat gefragt:
Daher jetzt mal die Frage an euch - sehr ihr das hier anders? Wenn Ja, was genau macht ihr dann? Wie setzt ihr eure Unit-Tests um, isoliert ihr abhängigkeiten? ..
einer unserer Azubis hat mir heute eine frage gestellt, die ich so nicht wirklich beantworten kann.
Ich bin ehrlich, ich schreibe nicht viele Unit-Tests, geschweige denn dass ich isolierungen mache.. aber genau da hängt das problem.
Mein Azubi hat gefragt:
Darauf hatte ich dann irgendwie keine Antwort parat.. Es kann ja schließlich nicht getestet werden ob ein Datenbank-Update erfolgreich ist, ob man mit bestimmten eingaben überhaupt ein ergebnis bekommt, usw. - Irgendwie bin ich hier etwas baff.Wenn man in einem Unit Test alles ordentlich isoliert, heißt keinerlei abhängigkeit besteht, sondern nur diese methode durchlaufen wird, ohne irgendwas anderes aufzurufen, sind das dann nicht einfach nur variablen zuweisungen und schleifen, die etwas zuweisen, die man mit Unit Tests testet? Was hat das dann genau für einen Sinn? - solange die Syntax richtig ist und keine falschen typen verwendet werden laufen die doch dann immer auf "Erfolgreich".
Daher jetzt mal die Frage an euch - sehr ihr das hier anders? Wenn Ja, was genau macht ihr dann? Wie setzt ihr eure Unit-Tests um, isoliert ihr abhängigkeiten? ..
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Datenbank-Operationen sind ein separates Thema.
Du gibst einer Methode in einem Unit Test vor, was rein geht und definierst, was du als Ergebnis erwartest.
Das machst du ja nicht nur einmal sondern mehrmals mit verschiedenen Werten um die Funktionalität deiner Methode sicherzustellen.
Zudem hast du einen Coverage Analyzer, der dir zeigt, wie viel von deinem Code wirklich durchlaufen wird. So kannst du sicherstellen, dass du wirklich alle Möglichkeiten abgefangen hast.
Besonders sinnvoll ist so etwas meines Erachtens für Regex-Funktionen und "wilde Abfragen".
Beispiel: Je nach Auftragsart, Warengruppe und Verkaufsorganisation soll ein Kennzeichen ermittelt werden (z.B. Lieferpriorität oder prozentualer Preisaufschlag).
Dann gibt es Regeln:
* für Auftragsart Z1 ist Lieferprio immer 1
* für alle anderen Auftragsarten gilt: bei Vkorg 1000, 2000 und 4600 ist Lieferprio immer 2
* Warengruppe 300 und 330 erzwingen eine Lieferpriorität 3, egal was vorher ermittelt wurde.
Damit hast du schon mal eine Komplexität, die nicht zu unterschätzen ist.
eventuell merkst du beim Erstellen der Testfälle auch, dass es Überschneidungen gibt und das Ergebnis nicht klar ermittelt werden kann.
Wenn du dann eine Testabdeckung von 100% hast, kannst du schon mal sicher sein, dass dein Code die Anforderungen abdeckt.
Und wenn nun noch Änderungen in der Logik kommen, dass beispielsweise bei vkorg 2000 und der Warengruppe 400 die Lieferpriorität immer 1 sein soll, dann kannst du dir deine bisherige Logik ziemlich zerschießen. Da du aber die bisherigen Fälle abgedeckt hast, kannst du so lange im Code herumändern, wie deine Unit Tests - plus die neu erstellten für die neue Anforderung - grün sind.
Mit Unit tests stellst du sicher, dass die Erwartungen, die du an das Ergebnis einer Methode hast, auch erfüllt werden.
Du gibst einer Methode in einem Unit Test vor, was rein geht und definierst, was du als Ergebnis erwartest.
Das machst du ja nicht nur einmal sondern mehrmals mit verschiedenen Werten um die Funktionalität deiner Methode sicherzustellen.
Zudem hast du einen Coverage Analyzer, der dir zeigt, wie viel von deinem Code wirklich durchlaufen wird. So kannst du sicherstellen, dass du wirklich alle Möglichkeiten abgefangen hast.
Besonders sinnvoll ist so etwas meines Erachtens für Regex-Funktionen und "wilde Abfragen".
Beispiel: Je nach Auftragsart, Warengruppe und Verkaufsorganisation soll ein Kennzeichen ermittelt werden (z.B. Lieferpriorität oder prozentualer Preisaufschlag).
Dann gibt es Regeln:
* für Auftragsart Z1 ist Lieferprio immer 1
* für alle anderen Auftragsarten gilt: bei Vkorg 1000, 2000 und 4600 ist Lieferprio immer 2
* Warengruppe 300 und 330 erzwingen eine Lieferpriorität 3, egal was vorher ermittelt wurde.
Damit hast du schon mal eine Komplexität, die nicht zu unterschätzen ist.
eventuell merkst du beim Erstellen der Testfälle auch, dass es Überschneidungen gibt und das Ergebnis nicht klar ermittelt werden kann.
Wenn du dann eine Testabdeckung von 100% hast, kannst du schon mal sicher sein, dass dein Code die Anforderungen abdeckt.
Und wenn nun noch Änderungen in der Logik kommen, dass beispielsweise bei vkorg 2000 und der Warengruppe 400 die Lieferpriorität immer 1 sein soll, dann kannst du dir deine bisherige Logik ziemlich zerschießen. Da du aber die bisherigen Fälle abgedeckt hast, kannst du so lange im Code herumändern, wie deine Unit Tests - plus die neu erstellten für die neue Anforderung - grün sind.
Mit Unit tests stellst du sicher, dass die Erwartungen, die du an das Ergebnis einer Methode hast, auch erfüllt werden.
Beitrag
von black_adept (Top Expert / 3946 / 105 /
886
)
»
Die Unit-Tests sollen doch genau die Syntax prüfen bzw. für einen möglichst breiten Bereich abdecken, dass die Syntax dort hinreichend korrekt ist.SaskuAc hat geschrieben:Wenn man in einem Unit Test alles ordentlich isoliert, heißt keinerlei abhängigkeit besteht, sondern nur diese methode durchlaufen wird, ohne irgendwas anderes aufzurufen, sind das dann nicht einfach nur variablen zuweisungen und schleifen, die etwas zuweisen, die man mit Unit Tests testet? Was hat das dann genau für einen Sinn? - solange die Syntax richtig ist und keine falschen typen verwendet werden laufen die doch dann immer auf "Erfolgreich".
Frag ihn mal nach einer Methode um aus einem Adressstring (Input) die Straße(Output1) und Hausnummer(Output2) zu extrahieren. Das ist eigentlich mein Lieblingsbeispiel, da du da genau das machst was der Azubi dich gefragt hat. Schleifen, Vergleiche Zuordnungen, ... Und am Ende kommt dann was raus.
Und dann gib ihm mal nach ein paar Standardadressen so ein paar nette Adressen mit Straßennamen wie "Wiesenweg 2b", "Neue Straße 42-44", " Straße des 17. Juli 42a-d c/o Meier " "
Oder lass ihn eine Methode implementieren, die von einer vorgegebenen Menge an Punkten und Verbindungen den kürzesten Weg sucht ( Dijkstra-Algorithmus ) und er soll dir irgendwie zeigen, dass seine Lösung korrekt ist. Auch hier sind ein paar hinreichend komplexe Beispiele, die mit den UnitTests durchgeführt werden kein schlechter Ansatz um die Korrektheit glaubhaft zu machen.
Oder schick ihn auf eine der einschlägigen CodingChallenge Seiten ( auch wenn die nicht für ABAP sind - irgendwas anderes wird er ja vielleicht schon können wie Java, JavaScript, C, ... " https://medium.com/coderbyte/the-10-bes ... b57645b654 ) bei denen häufig mit versteckten Tests gearbeitet wird um die Korrektheit einer Lösung anzunehmen.
Die Syntax prüft der Compiler, nicht der Unit test!black_adept hat geschrieben: Die Unit-Tests sollen doch genau die Syntax prüfen bzw. für einen möglichst breiten Bereich abdecken, dass die Syntax dort hinreichend korrekt ist.
Wie schon geschrieben, testen die Unit-Test nicht die Syntax sondern die Sematik.
Ein Unit-Test muss auch nicht immer nur eine Methode testen. Bei Klassen gibt es ja Klassenattribute (mit Getter und setter) und Methoden, welche Operationen auf diesen Attributen ausführen. Man setzt also einen Wert, führt eine Funktion aus und schaut im Getter, ob der Wert richtig ist.
So was ähnliches machen es die FRGN-Bausteine des BDT ja auch...
Ich habe mir angewöhnt, alle DB-Zugriffe oder auch Zugriffbausteine über einen DAO laufen zulassen. Nach außen gebe ich jedoch nur das Interface raus. Bei einem Unit-Test muss man dann "nur" die DB-Zugriff-Klasse gegen eine MOCK-Klasse austauschen. Sofern der Kunde dann auch Budget für den Unit-Test bereit hält, kann man diese auch noch nachträglich erstellen. Dies ist aber eher die Ausnahme.
Im Java hatte ich mal ein Projekt, wo mit Unit-Test Berechtigungen getestet werden mussten. So gab es eine Berechtigung zu einer Gruppe. Ein Nutzer gehöhrte zu einer oder mehrerer Gruppe. Ein Gruppe konnte wieder zu anderen Gruppen gehöhren. Ein Berechtigung zu mehreren Gruppen.
...und spätestens da musste eine Unit-Test her, damit man jede Konstellation Gruppe-User; Berechtigung-Gruppe, Gruppe-Gruppe testen konnte.
Ein Unit-Test muss auch nicht immer nur eine Methode testen. Bei Klassen gibt es ja Klassenattribute (mit Getter und setter) und Methoden, welche Operationen auf diesen Attributen ausführen. Man setzt also einen Wert, führt eine Funktion aus und schaut im Getter, ob der Wert richtig ist.
So was ähnliches machen es die FRGN-Bausteine des BDT ja auch...
Ich habe mir angewöhnt, alle DB-Zugriffe oder auch Zugriffbausteine über einen DAO laufen zulassen. Nach außen gebe ich jedoch nur das Interface raus. Bei einem Unit-Test muss man dann "nur" die DB-Zugriff-Klasse gegen eine MOCK-Klasse austauschen. Sofern der Kunde dann auch Budget für den Unit-Test bereit hält, kann man diese auch noch nachträglich erstellen. Dies ist aber eher die Ausnahme.
Im Java hatte ich mal ein Projekt, wo mit Unit-Test Berechtigungen getestet werden mussten. So gab es eine Berechtigung zu einer Gruppe. Ein Nutzer gehöhrte zu einer oder mehrerer Gruppe. Ein Gruppe konnte wieder zu anderen Gruppen gehöhren. Ein Berechtigung zu mehreren Gruppen.
...und spätestens da musste eine Unit-Test her, damit man jede Konstellation Gruppe-User; Berechtigung-Gruppe, Gruppe-Gruppe testen konnte.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Wenn du genau hinguckst, wirst du Tränen der Ergriffenheit und Rührung in meinen Augen finden. Nur noch ein Tipp: Das Prüfen über den GETter ist nur sinnvoll, wenn der wiederum nichts macht außer dem Auslesen. Darum prüfe ich immer direkt gegen das Attribut. Ich kenne durchaus auch GETter, die mit dem ermittelten Wert aus dem Attribut noch was machen, weil man so wie er im Attribut steht, nichts anfangen kann. Dann prüft man aber nicht das Attribut, sondern den GETter und das will man ja eigentlich nicht.msfox hat geschrieben:Ich habe mir angewöhnt, alle DB-Zugriffe oder auch Zugriffbausteine über einen DAO laufen zulassen. Nach außen gebe ich jedoch nur das Interface raus.
Zur Ursprungsfrage: Es gibt ja nicht nur SET-Methoden (für die ist der Unit-Test auch einfach zu schreiben und in der Tat trivial), sondern durchaus Methoden, die recht komplex sind und wilde Sachen machen. Aber selbst ein SETter kann komplex sein, wenn er z. B. den Attributswert auf Gültigkeit prüft, auf das richtige Format, etc. und dann lohnt sich ein Test wieder. Da es nicht wirklich Arbeit macht, einen Test für einen einfachen SETter zu schreiben (ich arbeite gerade daran, das zu automatisieren), sollte man ihn immer mit aufnehmen - nur für den Fall, dass der doch noch komplexer wird.
Die Frage ist gar nicht so wirr, wie sie aussieht.deejey hat geschrieben:Warum hast du dem Azubi nicht gesagt er soll nochmal tief in sich gehen bevor er so wirre Fragen stellt
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo,
nochmal was aus der Sicht eines Testers:
Der Unit Test soll beweisen, dass die Methode das tut, was sie fachlich machen soll.
Siehe auch das Beispiel mit den Verkaufsorganisationen.
Hintergrund ist die Testpyramide: Erst Unit, dann Funktion, dann Prozess.
Angenommen in einer Funktion (=Transaktion) werden fünf Methoden aufgerufen. Wenn es dort knallt, werden wohl die Methoden falsch befüllt oder es liegt am Coding in der Funktion.
An der Methode selber sollte es ja nicht liegen, da ja bereits erfolgreich getestet.
Wenn Du keine Unit Tests machst, weißt Du bei dem obigen Beispiel nicht, ob es an Methode 1, 2, 3, 4, 5, an der Versorgung der Methoden oder an der Funktion selbst liegt.
Der Tester oder die Abnahme wird nur sagen, es geht nicht und hoffentlich eine ordentlich beschriebene Abweichung liefern. Unit Tests erleichtern also das Leben des Programmierers bei späteren Fehlersuchen.
Außerdem lassen sie sich in der Regel gut automatisieren, was wichtig für sowas wie Continuous Integration ist.
Meine 2 Cent, schönes Wochenende.
nochmal was aus der Sicht eines Testers:
Der Unit Test soll beweisen, dass die Methode das tut, was sie fachlich machen soll.
Siehe auch das Beispiel mit den Verkaufsorganisationen.
Hintergrund ist die Testpyramide: Erst Unit, dann Funktion, dann Prozess.
Angenommen in einer Funktion (=Transaktion) werden fünf Methoden aufgerufen. Wenn es dort knallt, werden wohl die Methoden falsch befüllt oder es liegt am Coding in der Funktion.
An der Methode selber sollte es ja nicht liegen, da ja bereits erfolgreich getestet.
Wenn Du keine Unit Tests machst, weißt Du bei dem obigen Beispiel nicht, ob es an Methode 1, 2, 3, 4, 5, an der Versorgung der Methoden oder an der Funktion selbst liegt.
Der Tester oder die Abnahme wird nur sagen, es geht nicht und hoffentlich eine ordentlich beschriebene Abweichung liefern. Unit Tests erleichtern also das Leben des Programmierers bei späteren Fehlersuchen.
Außerdem lassen sie sich in der Regel gut automatisieren, was wichtig für sowas wie Continuous Integration ist.
Meine 2 Cent, schönes Wochenende.
Beitrag
von ralf.wenzel (Top Expert / 3776 / 176 /
262
)
»
Zunächst: Eine Transaktion ist (im OO) eine Menge von Methoden, die etwas tun in Objekten, die einen Zustand haben, der durch Attribute definiert ist. Im OO (wird es streng durchgezogen) gibt es also keine Funktion außerhalb von Methoden. Es gibt auch keine Funktion, die Methoden aufruft, sondern Methoden, die sich gegenseitig aufrufen. Man muss sich da von diesem Gedanken "Rahmenprogramm / Unterprogramm" lösen. Darum ist der Satz "Methoden falsch ODER es liegt man Coding in der Funktion" von Haus aus falsch.
Voraussetzung für eine korrekte Funktion einer Anwendung sind beanstandungsfrei durchlaufene Tests. Wenn alle Unit-Tests beanstandungsfrei durchlaufen werden, kann SO viel nicht mehr schieflaufen. Ansonsten hast du recht, Unit Tests erleichtern die Wartung. Schon deshalb, weil man Seiteneffekte ausschließen kann (ich baue eine neue Funktion ein und mache dabei drei bestehende Funktionen kaputt). Außerdem erklären sie, wie ein Objekt verwendet werden kann, denn nichts anderes macht ein Unit-Test.
Die Automatisierung ist dabei der Knackpunkt: Einen manuellen Testkatalog will kein Entwickler durchackern.
Ralf
Voraussetzung für eine korrekte Funktion einer Anwendung sind beanstandungsfrei durchlaufene Tests. Wenn alle Unit-Tests beanstandungsfrei durchlaufen werden, kann SO viel nicht mehr schieflaufen. Ansonsten hast du recht, Unit Tests erleichtern die Wartung. Schon deshalb, weil man Seiteneffekte ausschließen kann (ich baue eine neue Funktion ein und mache dabei drei bestehende Funktionen kaputt). Außerdem erklären sie, wie ein Objekt verwendet werden kann, denn nichts anderes macht ein Unit-Test.
Die Automatisierung ist dabei der Knackpunkt: Einen manuellen Testkatalog will kein Entwickler durchackern.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Hallo zusammen,
durch eure Antworten und durch den openSAP Kurs Writing Testable Code for ABAP ( sehr zu empfehlen, wenn man mit dem Thema einsteigen möchte ) habe ich jetzt wohl eine bessere Übersicht bekommen wieso, weshalb, warum und wie man am besten Unit Tests machen sollte. Ich glaube ich kann die Frage jetzt wohl meinem Azubi so beantworten, dass ich ihn auch dazu bekomme Unit-Tests zu schreiben.
Danke euch!
durch eure Antworten und durch den openSAP Kurs Writing Testable Code for ABAP ( sehr zu empfehlen, wenn man mit dem Thema einsteigen möchte ) habe ich jetzt wohl eine bessere Übersicht bekommen wieso, weshalb, warum und wie man am besten Unit Tests machen sollte. Ich glaube ich kann die Frage jetzt wohl meinem Azubi so beantworten, dass ich ihn auch dazu bekomme Unit-Tests zu schreiben.
Danke euch!
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
254
Views
Views
7
Antw.
Antw.
899
Views
Views
18
Antw.
Antw.
4102
Views
Views
10
Antw.
Antw.
2528
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.