Neue Themen als SAP Entwickler

Re: Neue Themen als SAP Entwickler

Nein - ich schreibe keine Unit-Tests und ich "mocke" auch nicht umher (was immer dies genau sein mag).

Im Rahmen eines OData-Projektes haben wir mal in SAP zig Testfälle aufgebaut und nach jeder Änderung automatisch abspielen lassen. Da gab es zwar auch Interfaces - das lag aber nicht an den Tests, sondern an der Umsetzung selbst.

Ansonsten habe ich mal innerhalb von Visual Studio für ein mittelschweres C#-WebScraping-Projekt ein paar Testfälle angelegt. Für diese brauchte ich aber auch keine Interfaces. Ein einzelnes Interface habe ich erst dann eingebaut, damit andere Entwickler einen eigenen Progress-Logger an meine Bibliothek andocken konnten.

Wenn man nun schon allein für Unit-Tests Interfaces braucht und damit sein Coding unnötig aufblähen muss, halte ich diese für fehlkonzipiert bzw. für nicht allgemein anwendbar, sondern wrsl. erst in Großprojekten. Aber wie gesagt: 0 Erfahrung damit.

Re: Neue Themen als SAP Entwickler

Meist teste ich während der Entwicklung mal flink in einem ZTMP-Report, ob und wie etwas komplexeres/vergessenes geht oder nicht - und da rufe ich auch direkt mal eine Methode oder FuBa. Wozu brauche ich da ein Interface?

Was ich nicht verstehe: wenn meine Methode DB-Daten abruft (und sei es über 5 verschachtelte Aufrufe über 3 andere Klassen), dann will ich beim Prüfen ja nicht verhindern, dass sie das tut, sondern im Gegenteil: genau sehen, dass sie es tut und wie sie damit weiter hantiert.

Um einen Druck zu verhindern, würde ich während des Testens im Debugger vorher aussteigen bzw. den Druckaufruf überspringen oder ein entsprechend optionales Test-KZ setzen, das ich während meines Tests setze und beim Druckaufruf abgefragt wird. Wenn man irgendeinen Druck prüft, wäre es ohnehin sinnvoll, per se ein Test- oder Vorschau-KZ oder gleich einen Dummy-Drucker setzen zu können.

Aber wieso um Herrgottswillen sollte man den grundsätzlichen Methodenablauf verhindern wollen?

Re: Neue Themen als SAP Entwickler

Dann würde ich das als mittelschweres Großprojekt einstufen, bei dem Interfaces, Unit-Tests und Mockingdödelingen offenbar sinnvoll wäre.

Aber sag mir bitte mal grob, wieviel Zeit für den ganzen Firlefanz draufgeht, inkl. Doku und sonstigem Overhead - und insbesondere, ob ein Entwickler, der Jahre später irgendwo da drin eine notwendige Änderung vornimmt, auch die ganzen Unit-Tests, Interfaces und weißderGeier verstehen und anpassen muss.

Übrigens, wieso nimmst du bei sovielen Fallkonstellationen keine Aussteuerung zur separaten Prozessierung vor, um derartige Interferenzen zu vermeiden? Leuchtet mir nicht ein.

Re: Neue Themen als SAP Entwickler

ralf.wenzel hat geschrieben: ↑

07.09.2024 19:27

Du sollst nicht die DB-Selektionsmethode testen, sondern die, die die Daten dann verarbeitet. Und Tests müssen systemunabh. sein, sonst funktioniert ein Programm auf einem, aber nicht auf dem anderen System. Weil zufällig eine bestimmte Datenkonstellation da ist oder nicht.

Moin Ralf,

ich fürchte, dass gaaaanz viele Leser in diesem Forum für SAP Endkunden arbeiten. Diese haben im Allgemeinen aber genau 1 System auf dem die Programme funktionieren müssen.
Ja - in der Theorie hast du recht und wenn du ein Sytemhaus bist, welches ein Addon an diverse andere SAP-(End)kunden weiterverkaufen will, dann sind Unit-Tests und all das was du beschreibst sicher sehr sehr wichtige Tools, weil ein Fehler bei einem Kunden üble Konsequenzen haben kann.
Aber gerade bei den SAP Endkunden ist die Prämisse häufig eine andere. Man weiß was man will ( *lach* - ihr wisst warum ich lache ) und das möchte man möglichst schnell und billig haben. Wenn's schief geht wird halt ein Korrekturreport geschrieben und beim nächsten Transport wird das Ganze gerade gezogen.
Das Problem ist hier nicht, dass niemand Unit-Tests haben möchte und bestreitet, dass diese sinnvoll sind und die Fehlerhäufigkeit verringern können, sondern dass es im Allgemeinen sehr schwierig ist zu begründen, dass der Zusatzaufwand, den man hier treiben muss der mindestens durch das hierdurch nötige andere Design und das Erstellen der Tests und evtl. dadurch zusätzlich anfallender Aufwand bei späterem Ändern der Prozesse des Kunden den Nutzen, den der Kunde hieraus gewinnt aufwiegt. Denn wie willst du berechnen wie viele Fehler tatsächlich hierdurch verhindert werden.
Die Person, die den Mehraufwand genehmigen muss, muss doch sein Budget weiter oben auch begründen und es ist ja so viel einfacher zu sagen "da waren Programmkorrekturen nötig weil sonst xxx passiert was uns Geld kostet " als "das könnte uns vielleicht zukünfig Geld sparen, wenn die Entwickler fehlerhaft arbeiten"

Re: Neue Themen als SAP Entwickler

Du brauchst mindestens drei Systeme auf denen deine Anwendung funktioniert.

Zweisystemlandschaften sind häufiger, als man denken sollte. Damit will ich nicht sagen, dass sowas ratsam ist, wohl aber, dass wir nicht entscheiden, wie viele Systeme sich der Kunde hinstellt.

Wenn du sagst "mir egal ob das im Testsystem funktioniert", kannst du da nicht zuverlässig testen.

Deshalb gibt es eine breite Palette an Cloningtools, mit denen man Echtdaten ins Testsystem replizieren kann - ggf. mit passender Anonymisierung. Im HCM-Bereich ist es bei Unternehmen, die selber abrechnen, nicht unüblich, jeden Monat den ganzen Personalstamm ins Testsystem zu clonen, dort abzurechnen, sich anzuschauen, mit welchen Fehlern (Datenfehler, also Pflegefehler, keine Bugs) die Abrechnung auf die Nase gefallen ist, diese Fehler im Prod zu korrigieren und dann dort die richtige Abrechnung zu machen.

Alles kann man sowieso nicht testen. Wenn aus irgendeinem Grund Dein Programm mit Belegen im Wert bis 864 € und dann wieder ab 866 € funktioniert und genau dann dumpt, wenn ein Beleg 865 € lautet, dann wirst Du das mit hoher Wahrscheinlichkeit auch mit Deinen automatisierten Tests nicht finden. Man muss einfach so viel testen, dass der Test als repräsentativ für alle typischen Anwendungsfälle gelten kann.

selbst wenn ich durch Änderung meines Entwicklungsobjekt ein völlig anderes zerschieße, von dem ich gar nicht wusste, dass es existiert

Wenn es solche Abhängigkeiten gibt, dann ist das etwas, was ich für schlechtes Design halte. Ein Include sollte nicht von mehreren Programmen genutzt werden (außer in sehr speziellen und übersichtlichen Sonderfällen). Wenn ich einer globalen Methode Parameter hinzufüge, um ihre Funktionalität zu erweitern, dann sollte diese neuen Parameter optional sein, und ich sollte darauf achten, dass die Methode sich wie gewohnt verhält, wenn ich sie ohne diese Parameter aufrufe.

Was Du hier beschreibst, klingt wie ein Kartenhaus, wo man nirgends anfassen darf, sonst bricht alles zusammen, weil es überall Abhängigkeiten und Verzahnungen Deiner Codes gibt, die niemand mehr überblickt. Ich will man hoffen, dass Deine Software nicht so gestrickt ist.

Und mir als Entwickler gibt es die Sicherheit, dass nicht am Tag nach Releasewechsel (wir arbeiten mit fünf Releases pro Jahr) das Telefon nicht mehr stillsteht.

Für sowas würde ich in meiner Naivität Betaversionen mit Pionierkunden machen. Diese bekommen die neue Version vor allen anderen, riskieren damit eher Bugs, haben im Gegenzug aber den Premiumsupport mit direkter Telefonnummer von jemand, der Ahnung hat und ihnen direkt helfen kann. So hat die SAP es z.B. auch gemacht, als sie S/4 HANA eingeführt haben (ich habe bei solch Pionierkunden gearbeitet, wenngleich nicht im FI-Modul, wo das zum Einsatz gekommen ist).

Dann ist bei Fehlern die Zahl der betroffenen Kunden sehr überschaubar, und der finale Rollout erfolgt, wenn sich die neue Programmversion bewährt hat.

Re: Neue Themen als SAP Entwickler

ich fürchte, dass gaaaanz viele Leser in diesem Forum für SAP Endkunden arbeiten. Diese haben im Allgemeinen aber genau 1 System auf dem die Programme funktionieren müssen.

Und wenn sie nur für Endkunden arbeiten. Gerade die wollen ja wissen, ob Änderungen am Coding zu nebeneffekten führen. Ich baue für einen Kunden gerade eine Schnittstelle. Ein bestimmter Dateninput soll einen bestimmten Datenoutput liefert. Genau dafür mache ich nach und nach auch Testfälle. Leider hat der Kunde keine Beispieldaten bereit gestellt. Diese trudeln erst beim Echttest aktuell ein. Kommt es da zum Fehler, so bilde ich das als Unit-Test nach. Am Ende müssen bei einer Korrektur immer noch alle vorherigen Tests laufen - wenn es keine Neuanforderungen gab.

Dann würde ich das als mittelschweres Großprojekt einstufen, bei dem Interfaces, Unit-Tests und Mockingdödelingen offenbar sinnvoll wäre.

Nein. Auch bei kleinen Projekten sind Unit-Test sinnvoll - insbesondere, wenn man es lernen will. Wenn man da etwas Übung hat, hat man schnell mal drei vier Test angelegt, um wenigstens ein Grundgerüst zu haben. Ich ärgere mich jedesmal, wenn es heißt: "Mach mal schnell, das muss doch NUR". Am Ende wird da ein riesen Report draus, ohne Unit-Test, schlecht strukturiert etc. Strukturierung ist hier das A und O. Wenn man nicht mit DAO und Interfaces arbeiten will, um mal die Datenzugriffschicht gehen eine MOCK-Schicht tauschen zu können, dann schreibe ich wenigsten die Methoden (oder FORM-Routinen) so, dass sie ohne DB-Zugriff auskommen. Wenn es dann zu einen Unit-Test gibt, schreibe ich das groß als Kommentar dran: "Kein DB-Zugriff, Unit-Tests beachten".

Aber sag mir bitte mal grob, wieviel Zeit für den ganzen Firlefanz draufgeht,

Sag du mir, wieviel Zeit die menschlichen Tester brauchen um alle Konstellationen bei jeder Codekorrektur manuell zu testen. Nehmen wir hier nur die SAP-Beleg, das sind sehr breite Tabellen. Kein menschlicher Tester kann korrekt prüfen, ob wirklich alle Werte beim Test in diesen Tabellen richtig sind. Das kann man nur maschinell machen. Genau solche manuellen Test hat früher in der alten Firma unsere Sekretärin gemacht. Die musste dann aber ganz genau dokumentiert bekommen, was sie drücken muss und welche Werte sie per Auge! vergleichen muss. Dauerte ca. 1 Woche und da war noch nicht einmal alles abgedeckt. Ich hab mich dann hingesetzt und daraus Unit-Test gemacht. Die liefen dann 2min durch und man konnte auch mal zwischendurch einfach die Tests durchlaufen lassen und nicht vor jeder Produktauslieferung.

Was ich nicht verstehe: wenn meine Methode DB-Daten abruft (und sei es über 5 verschachtelte Aufrufe über 3 andere Klassen), dann will ich beim Prüfen ja nicht verhindern, dass sie das tut, sondern im Gegenteil: genau sehen, dass sie es tut und wie sie damit weiter hantiert.

Dafür gibt es eben das DAO. Du willst an der Stelle nicht wissen, welche Daten auf der Datenbank laden. Du willst der Stelle wissen, ob die Daten bis dort hin korrekt angekommen sind. Bsp. - Methode INSERT_INTO_BUT000(). Im realen DAO schreibt die Methode die Daten in die BUT000. Im TestDAO prüft sie nur, ob die Daten wie gewünscht ankamen. Aber diese Art der Programmierung mit dem umfangreichen DAO ist laut CleanCode ABAP (bei Github) nicht so empflohlen, weil schwierig wartbar. Schlecht wartbar aber nur, wenn alles in eine Klasse stopft und dann 'zig KonstellationsKombinationen testen muss.

Re: Neue Themen als SAP Entwickler

Ralf hat geschrieben:

DeathAndPain hat geschrieben:Wenn aus irgendeinem Grund Dein Programm mit Belegen im Wert bis 864 € und dann wieder ab 866 € funktioniert und genau dann dumpt, wenn ein Beleg 865 € lautet, dann wirst Du das mit hoher Wahrscheinlichkeit auch mit Deinen automatisierten Tests nicht finden. Man muss einfach so viel testen, dass der Test als repräsentativ für alle typischen Anwendungsfälle gelten kann.

Genau. Dann ist man bei 200 Testfällen für EIN Formular. Und darum sollte man die automatisch durchführen, weil man da händisch nicht mehr nachkommt.

Du würdest in meinem Beispiel also einen Testfall für jeden nur denkbaren Betrag machen. Unter Berücksichtigung des Umstands, dass es auch Centbeträge gibt, wärst Du für den Bereich zwischen 0,01 € und 1000 € schon bei 100.000 "Testfällen".

Merkste selber, oder?

Ralf hat geschrieben:Abhängigkeiten hast du IMMER, das ist das Wesen des OO, dass Klassen wiederverwendet werden.

Einer Klasse, die wiederverwendet wird, sollte es egal sein, von wem. Beispielsweise habe ich mir eine globale Methode gebaut, der ich eine Tabelle von Personalnummern übergeben kann, und die Klasse sucht und liefert mir performant für alle Personalnummern den Personalbereich nebst der textuellen Bezeichnung desselben. Das kann man immer wieder in allen möglichen Reports brauchen.

Wenn ich an dieser Klasse bzw. Methode etwas machen möchte, dann ist für mich nur maßgeblich, dass dies die Funktionalität ist, die von dieser Methode bereitgestellt wird. Die kann man testen. Entweder sie funktioniert, oder sie funktioniert nicht. Da ist es mir völlig schnuppe, in wievielen (und welchen) Programmen ich diese Funktionalität nutze und dementsprechend diese Klasse mit einer Liste von Personalnummern aufrufe.

Ralf hat geschrieben:Da willst du ernsthaft behaupten, einer hätte da ÜBERBLICK über das Gesamtsystem???

Ich will behaupten, dass jede Klasse ein klar definiertes (und dokumentiertes) Verhalten haben sollte. Jeder Aufrufer muss sich überlegen, ob er für seine Zwecke diese Funktionalität brauchen kann oder doch lieber einen eigenen Code für seinen Anwendungsfall programmieren sollte. Da kann es nicht sein, dass eine Korrektur an solch Klasse wie die Dominosteine alle möglichen und unmöglichen Aufrufer zum Umfallen bringt und Deine Software ins Chaos stürzt, weil die Klasse irgendwie aufruferspezifisch unterschiedliche Verhaltensweisen an den Tag legt.

An dieser Stelle zahlen sich dann auch wieder zustandslose Methoden aus, denn bei denen hängt das Verhalten ganz eindeutig und klar definiert von dem ab, was ich ihnen über die Schnittstelle schicke und nicht von dem, was irgendwann vorher irgendwie in einem Attribut der Klasse versteckt worden ist und von niemandem mehr nachvollzogen werden kann.

Klar: Man darf die Funktionalität einer Methode, die bereits von irgendwem genutzt wird, nicht einfach abändern. Allenfalls kann man das machen, was ich zuvor schon erwähnt hatte: Optionale Parameter hinzufügen, die ergänzende Funktionalität aktivieren. Code, der diese Parameter befüllt, muss nach der Änderung entstanden sein (sonst würde er den Parameter nicht kennen) und daher an die Änderung angepasst sein.

Ralf hat geschrieben:Ich führe einen neuen Rententarif ein. Da wird monatelang (!) programmiert und gecustmized.

Aber erstmal nur für 50 Rentner und dann gucke ich mir ein paar Monate an, ob das produktiv reibungslos läuft und DANN biete ich das den anderen an?

Ganz genau. Wenn Du das als professionelle Lösung verkaufen willst, sollte es eine erfolgreiche Betaphase durchlaufen haben. Theoretische Tests zu machen und dann zu beten, dass es im praktischen Alltag genauso gut laufen wird und Deine theoretisch erdachten Testfälle alles abdecken, halte ich für naiv. Das endet so wie diverse Windowsupdates der letzten Zeit...

Ralf hat geschrieben:Abgesehen davon dass das gesetzlich nicht geht. Wenn die Politik bestimmt, dass bestimmte Rentenmodelle ab Tag X verfügbar sind, kann ich die nicht für Pilotrentner früher oder für andere später einführen.

Der Gesetzgeber räumt immer längere Umstellungszeiträume ein. Bei der eAU (elektronische Arbeitsunfähigkeitsbescheinigung, also das papierlose Attest) war es nach meiner Erinnerung ein Jahr zwischen Aktivschaltung des GKV-Servers (so dass man mit diesem kommunizieren und Atteste abfragen konnte) und dem Verbindlich-Werden dieser Lösung für alle Arbeitgeber.

Ralf hat geschrieben:Oder wenn eine Firma kommt und sagt „Wir brauchen einen Rententarif für unsere Mitarbeiter, weil wir denen Betriebsrente anbieten wollen. Der unterschreibt bei dir, wenn du denen mit Pilotrentnern kommst? Die sagen „oh, sorry, wir dachten Sie hätten das schon einmal gemacht — OK, dann wenden wir uns lieber an Profis mit Erfahrung“.

Tatsächlich glaube ich das nicht. Wenn solch ein Ansinnen an Dich gestellt wird, obgleich Du nicht Anbieter einer Software von der Stange dafür bist, dann wird von Dir eine Individuallösung erwartet. Da wird ein Projektplan aufgestellt mit einem Zeitplan für Spezifikation, Implementierung (ggf. als Zyklus) usw.. Dieser Zeitplan kann durchaus so aussehen, dass man sagt: "Bis Dezember entsteht ein Prototyp, den wir mit einen Monat lang mit einer Anzahl Testmitarbeiter fahren. Wenn alles rund läuft, bieten wir das ab Januar allen an."

Ganz konkret habe ich gerade an einem Projekt teilgenommen, bei dem in einem Konzern ESS/MSS (Employee Self-Service bzw. Manager Self Service über Fiori) eingeführt wurde. Da hat man auch gesagt, wir gehen erst mal mit zwei nicht so großen Gesellschaften des Konzern live, und wenn das alles rund läuft, rollen wir es schrittweise auch für den Rest des Konzerns aus.

Das ist ganz normale, professionelle Vorgehensweise.

Ralf hat geschrieben:Weil das ja so billig ist, zwei Prozesse parallel zu unterhalten.

Für eine Übergangsphase ist das einfach notwendig. Einen komplett neu entwickelten Prozess mit einem Schlag ohne praktische (!) Erfahrung für den ganzen Konzern live zu nehmen, wäre grob fahrlässig. Sicherlich ist es sinnvoll und notwendig, ordentlich zu testen. Aber dazu gehört eben auch eine Beta-Phase im Produktivsystem unter "Hyper-Care"-Bedingungen.