Best Practice Leitfaden Development - DSAG

die entscheidung Modifikation vs. z-Kopie vs. enhancement ist also nicht nur abhängig vom
realisierungsaufwand, sondern auch von einem möglichen Folgeaufwand.
> Keine der Möglichkeiten Modifikation/z-Kopie/enhancement hat nur Vor- oder nur nachteile,
es ist hier von Fall zu Fall zu prüfen, welche technik die wenigsten nachteile im speziellen Fall
mit sich bringt.
> es wird empfohlen, eine zentrale, formalisierte, technische dokumentation aller Modifikationen
einzurichten. Für Kopien und erweiterungen sollten geeignete templates bereitgestellt und es
sollte eine Pflicht zu deren Verwendung bestehen.
WEITERE QUELLEN:
saP schulungen BC425 und BC427
8.5 testBarKeit Von anWendunGen
um die testbarkeit von anwendungen zu gewährleisten, müssen die testanforderungen zu einem
sehr frühen zeitpunkt in der entwicklung festgelegt werden. Gewachsenes Coding nachträglich
testbar zu machen, ist meistens mit sehr hohem aufwand verbunden, der keine neue Funktionalität
bietet und daher in der Praxis sehr niedrig priorisiert wird.
um wirtschaftlich sinnvoll mit tests umzugehen, müssen tests automatisiert werden. dazu ist es
notwendig, die durchführung von tests wiederholbar zu machen. Versuchen sie, den Code so zu
schreiben, dass er von einem statischen Codeanalyse-Werkzeug weitestgehend untersucht werden
kann. das bedeutet, insbesondere auf dynamische anweisungen zu verzichten, da deren semantische
Bedeutung erst zur Laufzeit bekannt ist und von einem statischen tool nicht hinreichend
analysiert werden kann.
BEST PRACTICE: Verwenden sie von anfang an automatisierte tests (aBaP unit, eCatt), um die
automatisierung von tests zu einem „normalen“ Bestandteil der entwicklung zu machen.
BEST PRACTICE: saP unterstützt mit der test-Workbench testgetriebene entwicklungen durch
Modultests. testklassen werden als lokale Klassen angelegt und durch den zusatz „For testinG“
als solche kenntlich gemacht. der dort implementierte Programmcode wird lediglich ausgeführt,
wenn die anwendung über den Menüpunkt „Modultest“ in der aBaP-Workbench aufgerufen wird.
sogenannte risk-Levels geben die Kritikalität eines tests im Falle des scheiterns an und
systemeinstellungen verhindern gegebenenfalls, dass ein systemtest einer höheren risikostufe
ausgeführt wird.
im aBaP-umfeld ist in vielen Fällen die gelungene integration der datenbank ein Hindernis, wenn
es um die erstellung von wiederholbaren, automatisierten tests geht. im Vorfeld des tests müssen
die betroffenen einträge auf der dB in die Form gebracht werden, die für die jeweilige testausführung
erwartet wird, und Änderungen an der dB durch die testausführung müssen wieder beseitigt
werden, um andere tests nicht zu behindern.
55
Best Practice Leitfaden deveLoPment, 31. Januar 2013, © dsaG e. v.