Massentest mit Testklassen?
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
Hallo zusammen,
ist es möglich die Unit Tests zu einer Klasse mehrmals auszuführen?
Oder muss ich das in der Testklasse selber verwirklichen?
Hintergrund: Wenn ich in einer Methode eine Berechnung mache, dann kann ich natürlich einfach ausrechnen, wie lange die Ausführung dauert, wenn die Methode x Mal aufgerufen wird.
Wenn jedoch ein Klassenkonstruktor im Spiel ist und evtl. eine global definierte interne Tabelle gefüllt wird, dann kann die x-fache Ausführung einer Methode ganz andere Werte liefern.
Ich habe leider nichts gefunden.
Danke und Gruß
ist es möglich die Unit Tests zu einer Klasse mehrmals auszuführen?
Oder muss ich das in der Testklasse selber verwirklichen?
Hintergrund: Wenn ich in einer Methode eine Berechnung mache, dann kann ich natürlich einfach ausrechnen, wie lange die Ausführung dauert, wenn die Methode x Mal aufgerufen wird.
Wenn jedoch ein Klassenkonstruktor im Spiel ist und evtl. eine global definierte interne Tabelle gefüllt wird, dann kann die x-fache Ausführung einer Methode ganz andere Werte liefern.
Ich habe leider nichts gefunden.
Danke und Gruß
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Ein Massentest ist mir nicht bekannt. Also müsstest du deine Test-Methoden mehrmals aufrufen. Wenn es also um einen "Performance-Test" geht, kannst du ja eine weitere Testmethode schreiben in der du DO n TIMES die eigentliche Testmethode aufrufst.
Generell ist es ja möglich bei der Freigabe eines Transportauftrages die Unit-Tests aller enthaltener Objekte zu durchlaufen. Demnach müsste es einen Baustein oder einen Report dafür geben, den man im Hintergrund einplanen könnte und somit eine mehrfache Ausführung einer Testsuite bewirken könnte. Leider bin ich da nicht so tief in der Materie drinnen um dir den richtigen Fingerzeig zu liefern.
lg ADT
Das macht mich jetzt ein wenig stutzig. Ein Klassenkonstruktor wird nur EINMAL aufgerufen. d.h. auch die x-fache Ausführung einer Methode bewirkt keine Änderung in diesem Berreich.ewx hat geschrieben:Wenn jedoch ein Klassenkonstruktor im Spiel ist und evtl. eine global definierte interne Tabelle gefüllt wird, dann kann die x-fache Ausführung einer Methode ganz andere Werte liefern.
Generell ist es ja möglich bei der Freigabe eines Transportauftrages die Unit-Tests aller enthaltener Objekte zu durchlaufen. Demnach müsste es einen Baustein oder einen Report dafür geben, den man im Hintergrund einplanen könnte und somit eine mehrfache Ausführung einer Testsuite bewirken könnte. Leider bin ich da nicht so tief in der Materie drinnen um dir den richtigen Fingerzeig zu liefern.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Danke für deine Info! Das hilft mir weiter.
Natürlich wird der Constructor nur einmal aufgerufen. Deswegen kann man die Instantiierung + Ausführung auch nicht direkt hochrechnen, wenn das Objekt nur einmal erzeugt und dann die Methode x-mal aufgerufen wird.
Natürlich wird der Constructor nur einmal aufgerufen. Deswegen kann man die Instantiierung + Ausführung auch nicht direkt hochrechnen, wenn das Objekt nur einmal erzeugt und dann die Methode x-mal aufgerufen wird.
Beitrag
von ralf.wenzel (Top Expert / 3924 / 200 /
280
)
»
Hm, also eigentlich sind Testklassen dafür da, die Funktionsfähigkeit einer Methode zu ermitteln, für Massentests sind die weder gedacht noch geeignet.
Was spricht gegen die Laufzeitanalyse?
Was spricht gegen die Laufzeitanalyse?
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Ralf, wenn wir die Dinge immer nur dafür verwendeten, wofür sie gedacht waren... 
Gegen die Laufzeitanalyse spricht, dass ich für einen massentest entsprechende testdaten habe. Ich stelle mir aber vor, einen Massentest beliebiger Größe durchführen zu können, ohne dass ich dafür testdaten habe.
Gegen die Laufzeitanalyse spricht, dass ich für einen massentest entsprechende testdaten habe. Ich stelle mir aber vor, einen Massentest beliebiger Größe durchführen zu können, ohne dass ich dafür testdaten habe.
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Jein.ewx hat geschrieben:Gegen die Laufzeitanalyse spricht, dass ich für einen massentest entsprechende testdaten habe. Ich stelle mir aber vor, einen Massentest beliebiger Größe durchführen zu können, ohne dass ich dafür testdaten habe.
Zur Klarstellung: Gerade bei Testklassen hat man ja Testdaten.
Du willst dir das zusätzliche Anlegen von Testdaten für einen Massentest ersparen indem du die Testdaten aus deinen Testklassen nutzt.
Vielleicht würde dir hier ein anderes Design-Pattern für die DB-Abstraktion weiterhelfen: DAO (DataAccessObject)
Wir haben bei uns gerade damit angefangen und obwohl ich zu Beginn eher skeptisch war (der neue Kollege und was der schon wieder für Ideen hat *tztz*) muss ich sagen, dass man damit sehr leicht auch ein Testdatenverzeichnis anlegen kann, das man auch in mehreren Testklassen verwenden kann ohne Code zu duplizieren.
Grundsätzlich besteht ein DAO nur aus einem Interface das dem einzigen Zweck dient auf EINE Datenbanktabelle zuzugreifen (INSERT, UPDATE, DELETE, SELECT).
Dann gibt es eine Klasse die dieses Interface implementiert und alle Methoden für den DB-Zugriff bereitstellt.
In der Testklasse legt man nun einen Dummy-DAO an der anstatt des DB-Zugriffs mit internen Daten arbeitet.
Mein Vorschlag:
Man legt einfach diese Dummy-DAOs NICHT in der Testklasse ab, sondern als globale Klasse im Repository. Vorausgesetzt man hat ein einigermaßen brauchbares Benennungsschema kann man so in mehreren Testklassen auf dieselben Testdaten zugreifen. Was noch dazu kommt ist, dass man in einer Klasse ja auch mehrere Interfaces kombinieren kann und so einen ganzen Testfall der auch Abhängigkeiten abdeckt erzeugen kann.
Wenn man nun die Schnittstelle zum Austauschen des DAOs innerhalb eines "produktiven" Programms erreichen kann, könnte man auch ohne Testklassen und AUNIT-Framework einen Massentest anstoßen.
z.B. Report X bindet Report Y mittels Include ein und verändert im START-OF-SELECTION o.Ä. die DAOs auf die mit den Testdaten.
Volia: Nun kann man sogar Tests mit Benutzerinteraktionen durchführen ohne die Datenbank zu verändern.
Das sind mal Dinge die mir so durch den Kopf schweben, ich aber noch nicht Zeit hatte auszuprobieren
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Design Pattern sind eh geil!
Danke für die Anregung! Das schaue ich mir mal genauer an.
Danke für die Anregung! Das schaue ich mir mal genauer an.
Lustiger Weise hatte ich mit einem Kollegen das Konzept bereits erarbeitet... Allerdings nicht um Testdaten zu erzeugen, sondern um Testdaten in einer anderen Tabelle speichern zu können.
Das ist aber natürlich wirklich einfach zu erweitern
- IF_PROD für den Zugriff auf Produktive Daten aus Tabelle ZABC_PROD
- IF_TEST für den Zugriff auf Testdaten aus Tabelle ZABC_TEST
- IF_MASSTEST1 zur Erzeugung einer kleinen Testdatenmenge
- IF_MASSTEST2 zur Erzeugung einer unglaublich großen Menge von Testdaten
Danke für den Schubser in diese Richtung! Das werde ich so vorschlagen!
(happy)
Allerdings nicht um Testdaten zu erzeugen, sondern um Testdaten in einer anderen Tabelle speichern zu können. Das ist aber natürlich wirklich einfach zu erweitern
- IF_PROD für den Zugriff auf Produktive Daten aus Tabelle ZABC_PROD
- IF_TEST für den Zugriff auf Testdaten aus Tabelle ZABC_TEST
- IF_MASSTEST1 zur Erzeugung einer kleinen Testdatenmenge
- IF_MASSTEST2 zur Erzeugung einer unglaublich großen Menge von Testdaten
Danke für den Schubser in diese Richtung! Das werde ich so vorschlagen!
(happy)
Beitrag
von a-dead-trousers (Top Expert / 4396 / 223 /
1182
)
»
Vielleicht etwas anders:
IF_DAO_XYZ für den Zugriff auf Daten der Tabelle XYZ.
CL_DAO_XYZ implementiert IF_DAO_XYZ für den Zugriff auf die DB-Tabelle XYZ.
CL_DAO_XYZ_TEST implementiert IF_DAO_XYZ für den Zugriff auf die (internen) Testdaten der Tabelle XYZ.
Dort wo man auf die Daten zugreifen möchte (Manager) fügt man eine Methode SET_DAO_XYZ hinzu.
Global merkt man sich nur eine Variable vom Typ IF_DAO_XYZ.
Alle Zugriffe auf die Tabelle XYZ erfolgen nun nur über diese Variable.
Standardmäßig wird (z.B. im Constructor) immer eine Instanz vom Typ CL_DAO_XYZ angelegt.
Möchte man nun einen Test ausführen wird einfach mit SET_DAO_XYZ eine Instanz vom Typ CL_DAO_XYZ_TEST untergejubelt.
Stichwort: Mock-Object
lg ADT
IF_DAO_XYZ für den Zugriff auf Daten der Tabelle XYZ.
CL_DAO_XYZ implementiert IF_DAO_XYZ für den Zugriff auf die DB-Tabelle XYZ.
CL_DAO_XYZ_TEST implementiert IF_DAO_XYZ für den Zugriff auf die (internen) Testdaten der Tabelle XYZ.
Dort wo man auf die Daten zugreifen möchte (Manager) fügt man eine Methode SET_DAO_XYZ hinzu.
Global merkt man sich nur eine Variable vom Typ IF_DAO_XYZ.
Alle Zugriffe auf die Tabelle XYZ erfolgen nun nur über diese Variable.
Standardmäßig wird (z.B. im Constructor) immer eine Instanz vom Typ CL_DAO_XYZ angelegt.
Möchte man nun einen Test ausführen wird einfach mit SET_DAO_XYZ eine Instanz vom Typ CL_DAO_XYZ_TEST untergejubelt.
Stichwort: Mock-Object
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
ewx
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Nee, bestimmt anders! Du hast Recht, ich brauche ja das Interface nur einmal und muss es dann in die Objekte einbauen.a-dead-trousers hat geschrieben:Vielleicht etwas anders:
IF_DAO_XYZ für den Zugriff auf Daten der Tabelle XYZ.
CL_DAO_XYZ implementiert IF_DAO_XYZ für den Zugriff auf die DB-Tabelle XYZ.
CL_DAO_XYZ_TEST implementiert IF_DAO_XYZ für den Zugriff auf die (internen) Testdaten der Tabelle XYZ.
Danke!
http://uweku.github.io/mockA/a-dead-trousers hat geschrieben:Stichwort: Mock-Object
Warum kann man nicht mal fertig sein, mit Lernen...? *seufz*
Danke für deine Infos! In jedem Fall lernt es sich leichter, wenn man konkrete Anwendungsfälle hat.
Immerhin.
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1613
Views
Views
Automatische Generierung von Testklassen
von ralf.wenzel » 30.08.2014 12:07 • Verfasst in ABAP Objects®
von ralf.wenzel » 30.08.2014 12:07 • Verfasst in ABAP Objects®
5
Antw.
Antw.
2617
Views
Views
Testklassen unterscheiden von anderen lok. Kl.
von ralf.wenzel » 20.01.2015 17:31 • Verfasst in ABAP Objects®
von ralf.wenzel » 20.01.2015 17:31 • Verfasst in ABAP Objects®
Frage die ABAP Experten
Über diesen Beitrag
Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.
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.