The presentation describes how to build up unit testing in APEX application based on the metadata in APEX. The presentation was hold on the doag conference in nürnberg on 22.th of november 2012.
8. |
Umsetzung
Package
- für Logik
- für Regeln
Funktion für
- Seite
- Anwendung
Region auf Seite 0
- PLSQL Condition =>
APEX_APPLICATION.G_EDIT_COOKIE_SESSION_ID IS NOT NULL
APEX goes UNIT Testing – Oliver Lemm8
9. |
Umsetzung
Allgemeine Parameter
- APP_ID
- PAGE_ID
- MIN_MSG_TYPE
Weitere Parameter
- BOOLEAN
für APEX Komponenten
Datenbankobjekte
Inhaltliche Tests
APEX goes UNIT Testing – Oliver Lemm9
18. |
Weitere Möglichkeiten
Einsatz eines Metamodells
Tabelle der Seitenitems (Seite, Item-Name, Bezeichner, …)
Tabelle für Ausprägung der Elemente (Verknüpfung von Item und Datenmodell)
Tabelle der Datenmodelleigenschaften (Datentyp, Tabelle, Spalte, …)
Tabelle für Eigenschaften für fachliche Vorgaben (Pflicht, Bereich, Flags für weitere
Mechaniken (Schnittstellen / Kopie), fachlicher Bezeichner)
APEX goes UNIT Testing – Oliver Lemm18
19. |
Weitere Möglichkeiten
Kapselung als Region-Plugin
Integration von Mailversandt
Integration des DBMS_Scheduler
APEX goes UNIT Testing – Oliver Lemm19
20. |
Weitere Möglichkeiten
Regeldefinition in Tabelle
Export & Import von vorgefertigten Regeln
Integration/Prüfung von Theme Standards
Bugs & Fehler in Anwendung oder APEX anzeigen
APEX goes UNIT Testing – Oliver Lemm20
21. |
Fazit
Sehr gute Kombination von APEX & UNIT Testing
Anwendungsqualität steigern
Einarbeitung für neue Entwickler
Jederzeit Prüfung möglich
Transparenz
APEX goes UNIT Testing – Oliver Lemm21
22. ||
Besuchen Sie auch unsere weiteren Vorträge auf
der DOAG 2012
APEX goes UNIT Testing – Oliver Lemm22
Dienstag, 12 Uhr, Raum Riga
Dienstag, 13 Uhr, Raum Seoul
Dienstag, 14 Uhr, Raum Stockholm
Dienstag, 15 Uhr, Raum Kopenhagen
Dienstag, 16 Uhr, Raum Stockholm
Mittwoch, 13 Uhr, Raum Riga
Mittwoch, 15 Uhr, Raum Riga
Mittwoch, 16 Uhr, Raum Seoul
Donnerstag, 09 Uhr, Raum Istanbul
Donnerstag, 14 Uhr, Raum Konf. EG
Donnerstag, 15 Uhr, Raum Istanbul
Donnerstag, 16 Uhr, Raum Oslo
Dynamisch Unterschiede in Datensätzen auf Feldebene finden by S.O. Kelbert
Route to ASM by Ernst Leber
Automatische Generierung der ETL-Prozesse OWB vs. ODI by Irina Gotlibovych
Wiederverwendung von bestehendem PL/SQL Code in ADF Anwendungen by
Hendrik Gossens
„Managed Code“ mit OWB – Methoden und Wege by Bernhard Rosenberger
Dateizugriff mit new I/O 2 by Wolfgang Nast
WebServices in Java SE und EE by Wolfgang Nast
Das Mysterium OPatch by Volker Mach
Das größte APEX Projekt der Welt @ Union Investment by Niels de Bruijn
Testen mit Pfefferminzgeschmack by Birgit Kratz
APEX goes UNIT Testing by Oliver Lemm
SOA verspielt – rekursive BPEL Prozesse by Guido Neander
APEX - Datenbankzentrierte Entwicklung. Möglichst Standard Komponenten über deklarativen Ansatz
Layout - Aufteilung der Seite, Navigation & Templates
Validierungen- Anzeige von Fehler, Darstellung der Fehler, Verständlichkeit
Benutzerführung - Unterseiten, Tabs, Symbole/Icons zur Bearbeitung
Verarbeitung - dynamisch vs. Submit, zurück zur Vorseite, Informationen nach der Verarbeitung
Qualität => Fehler passieren immer, diese direkt erkennen erhöht die Qualität enorm
Effektivität => QS direkt beim Entwickeln
Anzeige => Anzeige der Probleme/Fehler direkt beim Entwickeln, kein separater Schritt => Vorteil zum Advisor, aber kein Ersatz
Automatisierung => Der Entwickler bekommt direkt Unterstützung und es wird vom System direkt unterstützt
Repository / Views => Einfach und schnell Informationen Auslesen & Auswerten
Datenbank => grundsätzliche Informationen auswerten
Projektvorgaben => Vorgaben gegen alle Metadaten auswerten
Umsetzungskonzept => Vorgaben bzgl. Verarbeitung, Layout, Validierungen und Benutzerführung ergeben sich daraus
Regeln => Über Regeln werden die einzelnen Prüfungen definiert. Diese sollen über SQL-Anfragen definierbar sein. Bezeichnung, Beschreibung, Regeltyp (info, warning, critical)
Unit Testing => Pro Bereich (Item, Button, …) Aussage über Erfolg
Seitenweise & App => darüber nur Informationen zur aktuellen Seite möglich. Applikationsweit für Shared Components nötig.
Integriert & unabhängig => Direkte Einbettung und Anzeige während der Entwicklung. Aufruf über Datenbank ohne Anwendung möglich.
Package => Einzelnes Packages um dies einfach zu integrieren. Getrennt um die Anpassungen zu Erleichtern. Logik wird bei zukünftigen Projekten gleich bleiben nur Regeln unterscheiden.
Packages größere Akzeptanz anstatt, Tabelle, Trigger & Sequenz
Funktion für => Seite (direkte integration) nur zusammenhängende Objekte prüfen
Region Seite 0 => Über Condition nur für Entwickler Ggf. spezielle Seiten ausklammern bzw. Testseiten
Allgemeine Parameter => APP_ID => Default auf Entwicklungssystem als „IN“ Parameter
PAGE_ID => APP_ID in Page 0 Aufruf
MIN_MSG_TYPE => ggf. möglich als Entwickler anzupassen
Weitere Parameter => Aktivierung / Deaktivierung von Teilprüfungen
Regions, Buttons, Tables, Navigation ….
APEX Objekte => Jedes Objekte was in APEX deklarativ erstellt werden kann und entsprechend als View zur Verfügung steht
Eigenschaften =>
Template => Namenskürzel
Ausrichtung => links für Komponenten für Textfield, Numberfield, oberhalb für große Elemente Textarea, Shuttle, rechts für Checkbox, Radiogroup
Condition => „Objekte“ mit „never“, allgemein Berechtigungsmechaniken
Message => APP_USER_MESSAGE
Name => Von Template auf Name bzw. Vorgaben aus Konzept beachten.
Reihenfolge => Zurück/Cancel, Speichern, Erstellen, Löschen (Sequenz Number)
Label => mit Hilfe => dann auch mit Hilfetext, sonst ohne und nur Label wenn nicht hidden
Datenbankobjekte => jegliche Objekte die per user_objcts bzw. all_objects zu prüfen sind
Eigenschaften
Name => Namenskonventionen pro Objekttyp _seq, _pkg, _id => PK ….
Seitenobjekte => Layer für APEX Seite => Seite vorhanden?
PK & FK => Jede Tabelle mit ID-Spalte und XXXX_XXXX_ID als FK?
Index & Constraint => zu jedem Constraint auch in Index
Tablespace => Indices im Indextablespace?
Objekte => Referenztabellen nicht leer, fachliche Tabellen müssen leer sein
Eigenschaften => Anzahl Einträge pro Tabelle
Schlüssel nach bestimmter Kennung
Eindeutigkeit über mehrere Tabellen hinweg
Seitengruppe
Ausrichtung
Template Namen
Optional (help/no help)
Check_page
Never Elemente
Metamodell - Extraktion der Informationen aus Umsetzungskonzept
Seitenitems - Bezeichner, Kennzeichnung als Hilfsitem oder zur Verarbeitung
Verknüpfung – mehrfache Benutzung eines Items in verschiedenen Kontexten
DB Modell – für Reports und zur Einarbeitung ins Datenmodell, Datentyp != Datentyp im DB Modell
Fachliche Vorgaben – Kapselung von mehreren Elementen und diversen fachlichen Eigenschaften für technische Mechaniken
Region-Plugin => Integration über Seite 0 als optional
Mailversandt => Auswertung von weiteren Systemen, Art und Inhalt der Mails klären => Zuordnung von Seiten zu Entwicklern
=> Unterschiedliche Auswertung je nach Aufgabe
DBMS_Scheduler => Job-Steuerung für Projektteam => Anstoßen von Mailversandt
Regeln in Tabelle => Eigenschaften bzw. Typ, etc. müssen abgebildet werden.
Exp & Import => vorgefertigte Regeln als Import & Export zur Verfügung stellen.
Theme Standards => Vorgaben der Templates
- Bugs => Bei Bugs in APEX diese Auflisten. Probleme wie zum Beispiel Fehler in DA oder anderen Punkten die nicht als Fehler ausgegeben werden diese anzeigen.
Kombination => Unit Testing lässt sich perfekt pro Themengebiet bzw. pro Seite definieren
Anwendungsqualität => Vorgaben lassen sich durch Automatisierung stark verbessern und Fehler fallen direkt auf
Einarbeitung => Vorgaben lassen sich direkt in der Anwendung als Prüfung anzeigen bzw. korrigieren lassen
Prüfung => Es kann jederzeit die Anwendung geprüft werden. Eine Prüfung kann auch von nicht technisch versierten Personen gemacht werden.
Transparenz => Innerhalb eines Packages lässt sich ein großteil der Vorgaben abbilden und wird immer aktualisiert durch Erweiterungen