Maschinelle Lohnsteuerberechnung für 2019

Getting started ... Alles für einen gelungenen Start.
57 Beiträge • Vorherige Seite 3 von 4 (current) Nächste
57 Beiträge Vorherige Seite 3 von 4 (current) Nächste

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von deejey (Specialist / 422 / 129 / 45 ) »
Bis vor 2 Jahren kannte ich Unittests garnicht, und war anfangs eher dagegen, mein Hauptargument war es sei zu aufwändig die vielen Testfälle zusammenzustellen und zu implementieren. Und klar ist es aufwändig, aber beim normalen Testen ist es ja nicht anders, auf Dauer fährt man mit UT eindeutig besser weil die Grundfunktionalität jederzeit in sekundenschnelle gewährleistet werden kann.

Folgende Benutzer bedankten sich beim Autor deejey für den Beitrag:
ralf.wenzel


gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
Ab welcher ABAP Version ist das Test Framework vernünftig implementiert?
Hat einer von euch, der UT lebt, eine gute Ressource zum lernen?

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3924 / 200 / 280 ) »
Was willst du da lernen? Wer OO kann, kann auch Unit Tests schreiben. Wer das nicht kann, sollte OO-Techniken lernen - weil man um die nicht herumkommt.

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
OO kann ich.
Aber irgendwo muss man ja anfangen. Man kann ja schlecht sagen: "so, jetzt mache ich Unit Test."
Das Framework will ja im Sinne des Erfinders genutzt werden.
Edit: oder ich fage mal so: hat jemand Best Practices zu dem Thema, die er empfehlen könnte?

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
Ein guter Anfang wäre Kapitel 3 von ABAP To The Future: ABAP Unit and Test-Driven Development

Ansonsten: Einfach machen und anfangen.
Das Schwierigste ist, die Methoden und Klassen so zu schreiben, dass sie (leicht) testbar sind. Und das kann man sich m.E. schwer anlesen. Das muss man machen und seine Erfahrungen sammeln.

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
Wie immer gilt: machen, machen, machen. :D
Danke für den Link!

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3924 / 200 / 280 ) »
Ich hab mal schnell was zusammengedengelt - zum grundsätzlichen Verständnis. Bitte beachten: Schnell zusammengedengelt, nach 21 Uhr und insbesondere nach einem anstrengenden Arbeitstag.

Disclaimer: Ich gewöhne mich zusehens an die in Java übliche Notation: Interfaces heißen wie Eigenschaften, etc. ZCL_ und ZIF_ finde ich schon deshalb gruselig, weil das wichtige Zeichen klaut - insbesondere wenn man in Kundennamensräumen arbeitet (wie ich, der ja Produktentwicklung macht). Da ist man dann schnell bei /KUNDE/CL_.... Da kämpft man um jedes Zeichen, um lesbare Namen zusammenzukriegen, denn bei 30 ist Schluss.

Also, wir brauchen eine Klasse, die getestet werden soll. Für die brauchen wir erstmal ein Interface (weil wir es ja gescheit machen wollen, man programmiert nicht gegen konkrete Klassen....):

Code: Alles auswählen.

interface ZTESTABLE
  public .


  methods READ_MATNR
    returning
      value(R_MATNR) type MATNR .
  type-pools ABAP .
  methods IS_NUMERIC
    importing
      !I_MATNR type MATNR
    returning
      value(R_IS_NUMERIC) type ABAP_BOOL .
endinterface.
Jetzt noch die Klasse dazu:

Code: Alles auswählen.

class Z2BE_TESTED definition
  public
  create public .

public section.

  interfaces ZTESTABLE .

  aliases IS_NUMERIC
    for ZTESTABLE~IS_NUMERIC .
  aliases READ_MATNR
    for ZTESTABLE~READ_MATNR .
protected section.
private section.
ENDCLASS.



CLASS Z2BE_TESTED IMPLEMENTATION.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method Z2BE_TESTED->ZTESTABLE~IS_NUMERIC
* +-------------------------------------------------------------------------------------------------+
* | [--->] I_MATNR                        TYPE        MATNR
* | [<-()] R_IS_NUMERIC                   TYPE        ABAP_BOOL
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD ztestable~is_numeric.

  IF i_matnr CO '1234567890 '.
    r_is_numeric = abap_true.
  ENDIF.

ENDMETHOD.


* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method Z2BE_TESTED->ZTESTABLE~READ_MATNR
* +-------------------------------------------------------------------------------------------------+
* | [<-()] R_MATNR                        TYPE        MATNR
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD ztestable~read_matnr.

*** Hier steht eine Logik, die eine Materialnummer oder
*** irgendwas anderes ermittelt.

  SELECT SINGLE matnr FROM mara INTO r_matnr.

ENDMETHOD.
ENDCLASS.
Mir ist nichts Besseres eingefallen, als eine MATNR auf numerisch / nicht numerisch zu prüfen (wobei wir Leerzeichen ignorieren). Etwas praxisfern, aber ich will ja was Verständliches bauen und nix Komplexes. Die Klasse liest also irgendeine MATNR und gibt sie zurück, sodann prüft sie, ob die MATNR numerisch ist oder nicht. Das sollten wir natürlich so im Test nicht machen, weil wir nicht wissen, welche Nummer ausgelesen wird. Wenn ich die Voraussetzung nicht kenne, kriege ich keine reproduzierbaren Ergebnisse. Also sorgen wir für solche:

Wir klicken auf "Lokale Testklassen" und bauen uns erstmal eine Hilfsklasse für die Verifikation, die von der zu testenden Klasse erbt:

Code: Alles auswählen.

*----------------------------------------------------------------------*
*       CLASS lth_2be_tested_ok DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lth_2be_tested_ok DEFINITION
INHERITING FROM z2be_tested.

  PUBLIC SECTION.
    METHODS:
      ztestable~read_matnr REDEFINITION.

  PRIVATE SECTION.
    CLASS-DATA:
      instance TYPE REF TO lth_2be_tested_ok.

ENDCLASS.                    "lth_2be_tested_ok DEFINITION

*----------------------------------------------------------------------*
*       CLASS lth_2be_tested_ok IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lth_2be_tested_ok IMPLEMENTATION.

  METHOD ztestable~read_matnr.
    r_matnr = '123'.
  ENDMETHOD.                    "read_matnr

ENDCLASS.                    "lth_2be_tested_ok IMPLEMENTATION

Wie du siehst, wird die Methode READ_MATNR( ) redefiniert und liefert immer ein numerisches Ergebnis zurück. Ein Analogon brauchen wir jetzt noch für die Falsifikation, auch eine lokale Klasse, die von der zu testenden Klasse erbt:

Code: Alles auswählen.

*----------------------------------------------------------------------*
*       CLASS lth_2be_tested_nok DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lth_2be_tested_nok DEFINITION
INHERITING FROM z2be_tested.

  PUBLIC SECTION.
    METHODS:
      ztestable~read_matnr REDEFINITION.

  PRIVATE SECTION.
    CLASS-DATA:
      instance TYPE REF TO lth_2be_tested_nok.

ENDCLASS.                    "lth_2be_tested_nok DEFINITION

*----------------------------------------------------------------------*
*       CLASS lth_2be_tested_nok IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS lth_2be_tested_nok IMPLEMENTATION.

  METHOD ztestable~read_matnr.
    r_matnr = '12X'.
  ENDMETHOD.                    "read_matnr

ENDCLASS.                    "lth_2be_tested_nok IMPLEMENTATION

Hier wird in der Redefinition immer ein nicht-numerisches Ergebnis zurückgeliefert.

Wichtig dabei: Wir testen die Methode IS_NUMERIC( ), wir wollen NUR wissen, ob DIESE Methode korrekt arbeitet. Darum ist im Grunde völlig egal, was in READ_MATNR( ) steht und was sie zurückliefert. Und wenn wir nur IS_NUMERIC( ) testen wollen, müssen wir nur darauf achten, dass DIESE Methode im Original durchlaufen wird.

Und jetzt die eigentliche Testklasse:

Code: Alles auswählen.

*----------------------------------------------------------------------*
*       CLASS ltc_aunit_example DEFINITION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS ltc_aunit_example DEFINITION FOR TESTING
  DURATION SHORT
  RISK LEVEL HARMLESS.

  PRIVATE SECTION.
* ================

*---------------------------------------------------------------------*
*       static attributes
*---------------------------------------------------------------------*
    CLASS-DATA:
      "! class under test
      cut TYPE REF TO ztestable.

*---------------------------------------------------------------------*
*       instance attributes
*---------------------------------------------------------------------*

*---------------------------------------------------------------------*
*       class-constructor and -destructor
*---------------------------------------------------------------------*
    CLASS-METHODS:
       class_setup,
       class_teardown.

*---------------------------------------------------------------------*
*       constructor and -destructor
*---------------------------------------------------------------------*
    METHODS:
      setup,
      teardown.

*---------------------------------------------------------------------*
*       test methods
*---------------------------------------------------------------------*
    METHODS:
      verification FOR TESTING,
      falsification FOR TESTING.

ENDCLASS.       "ltc_aunit_example

*----------------------------------------------------------------------*
*       CLASS ltc_aunit_example IMPLEMENTATION
*----------------------------------------------------------------------*
*
*----------------------------------------------------------------------*
CLASS ltc_aunit_example IMPLEMENTATION.
  METHOD class_setup.

  ENDMETHOD.       " class_setup

  METHOD setup.

  ENDMETHOD.       " setup

  METHOD verification.

    DATA:
      cut TYPE REF TO lth_2be_tested_ok.

    CREATE OBJECT cut.

    cl_aunit_assert=>assert_equals(
      exp   = abap_true
      act   = cut->is_numeric( cut->read_matnr( ) )
      msg   = 'Fehler: MATNR ist nicht (rein) numerisch'
      level = cl_aunit_assert=>critical
      quit  = cl_aunit_assert=>method
    ).

  ENDMETHOD.       " verification

  METHOD falsification.

    DATA:
      cut TYPE REF TO lth_2be_tested_nok.

    CREATE OBJECT cut.

    cl_aunit_assert=>assert_equals(
      exp   = abap_false
      act   = cut->is_numeric( cut->read_matnr( ) )
      msg   = 'Fehler: MATNR ist nicht (rein) numerisch'
      level = cl_aunit_assert=>critical
      quit  = cl_aunit_assert=>method
    ).

  ENDMETHOD.                    "falsification

  METHOD teardown.

  ENDMETHOD.       " teardown

  METHOD class_teardown.

  ENDMETHOD.       " class_teardown
ENDCLASS.       "ltc_aunit_example
Was macht diese Testklasse? Im ersten Falle wird falsifiziert (Testmethoden werden in alphabetischer Reihenfolge durchlaufen, darum geht Falsifikation vor Verifikation), also geprüft, ob ein falsches Ergebnis auch als falsch erkannt wird. Sollte IS_NUMERIC( ) bei '12X' ausgeben, dass das es sich um ein numerisches Ergebnis handelt (ABAP_TRUE), muss ein Fehler angezeigt werden. Bei der Verifikation genau andersrum: Sollte IS_NUMERIC( ) bei '123' ausgeben, dass es sich NICHT um ein numerisches Ergebnis handelt, muss ebenfalls ein Fehler angezeigt werden.

Dieses Testergebnis ist jederzeit auf jedem SAP-System reproduzierbar, unabhängig vom Datenstand. Man kann die Methode sogar testen auf einem System, auf dem gar keine Materialstammdaten vorhanden sind. In diesem Falle sind es nur zwei Tests, weil das Ergebnis binärer Natur ist. Methoden, die mehr unterschiedliche Ergebnisvariationen haben, sollte man entsprechend oft testen (das kann man auch generisch machen, wenn man das will). Es gibt auch keine möglichen Fehlerquellen, die man falsifizieren könnte. Ich würde zu jeder Ausnahme, die eine getestete Methode werfen kann, einen Testfall produzieren um festzustellen, ob die Ausnahme auch wirklich geworfen wird. Und im "Geradeaus-Fall" erzeugt man natürlich eine Fehlermeldung, wenn eine Ausnahme den Test beendet.

Wenn du die Unit-Tests nun ausführst, wirst du feststellen, dass nur eine S-Meldung kommt. Ich habe mal einen Fehler produziert, damit du siehst, wie das dann aussieht:
AUNIT.png
So, ich hoffe zum grundsätzlichen Verständnis von Unit-Tests beigetragen zu haben ;) Und bitte nicht auf Kleinigkeiten gucken, ich sitze seit 14h am Rechner. Zum Beispiel heißen die Testmethoden falsch, eigentlich sollten die IS_NUMERIC( ) und IS_NOT_NUMERIC( ) heißen, aber ich wollte nicht zu viele Methoden in verschiedenen Klassen mit demselben Namen haben (du sollst es ja verstehen).

Wenn du Fragen hast: Immer raus damit. Aber ich hab den Artikel jetzt 5x gelesen und finde eigentlich nix, was nicht verständlich ist.

Noch ein Wort dazu, was das bringt: Erstens verifizieren wir für jeden möglichen Wert, dass die Methode funktioniert. Zweitens falsifizieren wir, dass die Methode falsche Ergebnisse liefert. Drittens zeigen wir einem Entwickler, wie die Methode eingesetzt wird. Jetzt kann man sagen "das sieht man doch", aber bei komplexen Methoden mit n Parametern ist das nicht immer so einfach. Wir schreiben also eine Benutzungsanleitung in der Sprache, die jeder Entwickler versteht: In ABAP. Man sollte nie vergessen: Man schreibt den Test nicht nur, um zu sehen, ob man richtig programmiert hat -- sondern eben auch für die Zukunft, wenn man mal was ändert. So kann man auf Knopfdruck die Funktionen einer beliebig komplexen Klasse prüfen und Fehlfunktionen ausschließen (insbesondere kann man dafür sorgen, dass Transporte mit nicht funktionierenden Unit-Tests gar nicht freigegeben werden können).

Zum Aufwand ist folgendes zu sagen: Mit Mustern (ich erwähnte es schon) kann man sich das Leben deutlich leichter machen, gerade wenn man EXITs benutzt, in denen man sich sehr dynamisch Testklassenmuster zusammendengeln kann. Die Arbeit macht man sich einmal mit dem Erfolg, dass man sich viel, viel Arbeit in vielen, vielen Tests erspart.

So habe ich ein Muster für eine Hilfsklasse, die von der zu testenden Klasse erbt. Muster einfügen, Muster einfügen, Hilfsklassen entsprechend benennen, Redefinitionen für READ_MATNR schreiben. Fertig. Muster für Testklasse einfügen, zwei Testmethoden auscodieren, fertig. Dauert (für diesen einfachen Fall) vielleicht zehn Minuten (an diesem Artikel habe ich deutlich länger geschrieben). Je mehr Übung man hat und je mehr man bei der Entwicklung der zu testenden Klasse schon im Hinterkopf hat, dass man testbares Coding schreiben muss, umso weiter runter geht der Testaufwand.


Ralf *wo war noch gleich die Fleißkärtchen-Ausgabestelle? :D

Nachtrag: Der Tipp von Enno ist hervorragend, das Buch ist klasse. Weil es auch sehr humorvoll geschrieben ist (wer Paul kennt, weiß, dass er wirklich so witzig ist).

Folgende Benutzer bedankten sich beim Autor ralf.wenzel für den Beitrag (Insgesamt 4):
ewxnickname8tm987456Romaniac

Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
ja, nicht schlecht, aber... ;)

IS_NUMERIC oder IS_NOT_NUMERIC sollte m.E. unabhängig von dem Lesen der Matnr sein.
Dein Beispiel ist deswegen zu kompliziert.
Und nicht nur das: Du musst die eigentliche Methode IS_NUMERIC in jedem Testfall neu definieren!

Die Testklasse sollte IMHO aus Methoden bestehen, die nach und nach alle Positiv als auch Negativprüfungen abdecken:

Code: Alles auswählen.

METHOD test_1234XY.
cl_aunit_assert=>assert_equals(
      EXP   = abap_false
      act   = cut->is_numeric( '1234XY' )
      msg   = 'Fehler: MATNR ist nicht (rein) numerisch' ).
ENDMETHOD.
Und genau das macht aber auch die Schwierigkeiten eines Unit tests aus:
Wann ist eine Matnr "numerisch"?
Ist "0000001234" numerisch? klar!
Und " 00001234"?
Oder "000012345 "?
Oder sogar " 1 2 3 4"?
Und was ist mit "123-4"?

Code: Alles auswählen.

METHOD test_1234_space.
cl_aunit_assert=>assert_equals(
      EXP   = abap_false
      act   = cut->is_numeric( '1234     ' )
      msg   = 'Fehler: MATNR ist nicht (rein) numerisch' ).
ENDMETHOD.
Was wird toleriert? Was muss evtl. vorher umgewandelt, angepasst, konvertiert werden?

Aber wenn das genau definiert ist, dann sind genau dafür die Unit Tests klasse!
Weil bei einigermaßen komplexen Anpassungen (SHIFT LEFT DELETING LEADING space, OVERLAY, ALPHA_CONVERSION, REPLACE "/" WITH SPACE, CONDENSE...) kann man sich schnell funktionierendes Coding wieder kaputt machen...

Mit Unit Tests dokumentiert man sozusagen auch, mit welchen Eventualitäten man rechnet oder welche schon vorgekommen sind.

Und auch hier hat man natürlich wieder zusätzliche Aufwände: Wenn der Fachbereich sagt: " 1234" kann über die Schnittstelle kommen und das IST numerisch!, dann muss man genau diesen Testfall, den man vorher als FALSCH eingestuft hat, ändern.

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag (Insgesamt 2):
nickname8tm987456


Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3924 / 200 / 280 ) »
Alles richtig, ich wollte mit READ-MATNR( ) zeigen, wie man einen DB-Zugriff mocken kann, irgendwer hatte das hier gefragt.

Das ist ja eh kein Praxisfall, sondern ein halbwegs praxisnahes Lehrbeispiel. Dein Beispiel funktioniert z. B. nicht, wenn IS-NUMERIC( ) keine Imorting-Parameter hat, sondern READ_MATNR( ) selbst aufruft. Dann kommst du uns Mocken nicht herum.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von Thomas R. (Expert / 755 / 78 / 34 ) »
Hallo,
zum Einstieg in Unit Tests gibt es einen Kurs bei OpenSAP
https://open.sap.com/courses/wtc1
Soviel ich weiß kann der zum Selbststudium noch freigeschaltet werden.

MfG
Thomas R.

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von nickname8 (Specialist / 134 / 17 / 19 ) »
Thomas R. hat geschrieben:Hallo,
zum Einstieg in Unit Tests gibt es einen Kurs bei OpenSAP
https://open.sap.com/courses/wtc1
Den Kurs habe ich mir damals angeschaut und wer die Videos + Präsis davon haben will, melde sich bei mir. Fand den auch gut. Aber leider haben die äußeren Umstände nicht gepasst, dass ich mich da total reingehängt habe (meine Frau war hoch schwanger, da hat man anderes im Kopf... :D ). Mir fehlt(e) so eine Zusammenfassung wie Ralf sie geliefert hat.

Ralf: Ein Mega-Dankeschön!
Enno: Danke für die Ergänzung.

(erstmal) eine Frage habe ich tatsächlich:
- Im openSAP-Kurs haben die gesagt, das man nur public Methoden testet (kann?/darf?) Ich mache aber nur die Methoden public, die auch wirklich benötigt werden. Intern habe ich aber viele kleine Methoden, um Code auszulagern. Bin kein Fan von 150 Zeilen ABAP-Coding pro Methode :mrgreen: ). Wie testet man Klassen-interne Funktionalitäten?

LG

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3924 / 200 / 280 ) »
Die Aussage ist falsch. Wenn du die Testklasse als local friend der CUT deklarierst (wie in meinem Beispiel), hast du Zugriff auf alle privaten Komponenten.

Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von Thomas R. (Expert / 755 / 78 / 34 ) »
Wobei sich die Frage stellt wie sinnvoll es ist private Methoden zu testen. Zumindest wenn ich die Public-Methoden per Test-Unit testen kann.

Wenn ich eine öffentliche Methode "Baugrube ausheben" habe und dafür Testfälle, dass bei Vorgabe der Maße auch wirklich die richtige Größe am richtigen Platz ausgehoben wird so ist es m.E. nicht unbedingt sinnvoll auch die darin genutzte private Methode "Schaufel benutzen" teste.
Denn irgendwann werde ich darauf kommen, dass dies etwas langsam ist :shock: und durch die Methode "Bagger benutzen" austauschen :D .
Solange nach dem Austausch der Methode meine Tests für "Baugrube ausheben" noch passen ist alles in Ordnung :up:.

MfG
Thomas R.

Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
Thomas R. hat geschrieben:Wobei sich die Frage stellt wie sinnvoll es ist private Methoden zu testen. Zumindest wenn ich die Public-Methoden per Test-Unit testen kann.
Den Einwand habe ich auch gerade woanders gelesen und kann ihn überhaupt nicht nachvollziehen!

Private und geschützte Methoden sind doch genau so wichtig wie die öffentlichen Methoden!
Ich muss doch auch sicherstellen, dass Methode BAGGER funktioniert!

Folgende Benutzer bedankten sich beim Autor ewx für den Beitrag:
ralf.wenzel


Re: Maschinelle Lohnsteuerberechnung für 2019

Beitrag von ralf.wenzel (Top Expert / 3924 / 200 / 280 ) »
Thomas R. hat geschrieben:Wobei sich die Frage stellt wie sinnvoll es ist private Methoden zu testen. Zumindest wenn ich die Public-Methoden per Test-Unit testen kann.
Alles, was du nicht testest, funktioniert potentiell nicht (immer). Deshalb sollte man natürlich jede einzelne Methode testen, selbst SETter und GETter, weil potentiell diese Methoden weit mehr tun als ein Attribut zu schreiben oder zu lesen. Darum sind sie ja da: Um das Attribut gegen wildes Beschreiben zu schützen und nur zulässige Werte durchzulassen (und schon habe ich einen Testfall mit Verifikation und Falsifikation). Ich durchdenke gerade, wie ich Testmethoden für SETter und GETter in meine Vorlagen mit aufnehmen kann, damit man solche Prüflogiken nur noch reinschreiben muss, wenn das denn nötig wird. Aber das ist dann schon recht komplex, weil man abgleichen muss, welche SETter und GETter schon im Test sind und welche nicht (und gerade die vom Entwickler angereicherten Tests kann man ja nicht einfach löschen und neu generieren). Da fehlt es mir derzeit schlichtweg an der Zeit.


Ralf
Bild
Ralf Wenzel Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
PublikationenUngarische NotationXing

Vergleichbare Themen

2
Antw.
1723
Views
maschinelle Zahlung per Bankeinzug?
von hakan_gueven@yahoo.de » 07.05.2008 09:51 • Verfasst in Financials
5
Antw.
2082
Views
Maschinelle Änderung von Varianten
von KlausB » 02.03.2009 17:31 • Verfasst in ABAP® Core
4
Antw.
11972
Views
maschinelle Buchung mehr als 999 Positionen
von schnaku » 13.02.2009 11:26 • Verfasst in Financials
3
Antw.
3301
Views
Maschinelle Kopieren von Rollen funktioniert nicht
von Adalan » 20.08.2012 09:35 • Verfasst in ABAP® Core

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Daten an Tabelle binden
Gestern von Bright4.5 1 / 511
aRFC im OO-Kontext
vor 4 Wochen von ralf.wenzel 1 / 2146
Hilfe bei SWEC/SWE2
letzen Monat von retsch 1 / 8742