Oft fällt die Frage, ob man PL/SQL überhaupt automatisiert testen kann. Deshalb behandelt dieser Vortrag u.a. die folgenden Themen: - Welche Fehler will ich mit Testautomatisierung überhaupt vermeiden? - Änderung des Datenmodells - Änderung bestehender Programme - Datenbank-Patching/-Upgrade - Wie sieht eigentlich mein Entwicklungsprozess aus? - Wie viele Entwickler habe ich? - Welches Wissen haben meine Entwickler? - Muss ich branchen? - Muss ich häufig meinen Code umstrukturieren? - Welche Frameworks gibt es für die Testautomatisierung? - SQL Developer - Quest Code Tester - utPLSQL - ruby-plsql-spec - Welche Voraussetzungen muss ich erfüllen? - Datenbankversionen - Infrastruktur - Für welchen Zweck eignet sich welches Framework? - Unterstützung von CI-Servern - Unterstützung von Build Systemen wie z.B. Maven - Test Driven Development Neben der Theorie sehen Sie natürlich auch in Demo's, wie sich der Testcode "anfühlt". Der Vortrag soll Ihnen eine Entscheidungsgrundlage liefern, ob Sie demnächst auch automatisch testen wollen und können!

1. PL/SQL: Drum test-automatisiere, wer sich
sich ewig bindet!
Torsten Kleiber, DOAG 2017

2. IKB – Bank des Mittelstands
IKB im Überblick
Leistungsspektrum
Regionale Präsenz
Anmerkung: Kennzahlen per 31. März 2017 (Geschäftsjahr 1. April bis 31. März)
1) Die CET 1-Quoten wurden nach aktuellem Rechtsstand der CRR zum jeweiligen Stichtag inklusive Übergangsvorschriften sowie der bekannten Interpretationen der Aufsicht und deren Auslegung ermittelt. Es ist nicht auszuschließen, dass zukünftige EBA-
/EZB-Standards/Interpretationen bzw. sonstige aufsichtliche Handlungen retrograd zu einer abweichenden CET 1-Quote führen können.
2
▪ Seit über 90 Jahren Finanzierungspartner
des Mittelstands
▪ ca. 1.100 Kundengruppen in Deutschland
und Europa und ca. 23.000 Kundengruppen
im Leasing-Geschäft
▪ Aktionäre: Lone Star 100 %
▪ 1.433 Mitarbeiter (VAK), davon 469 IKB
Leasing
▪ Bilanzsumme: 19,2 Mrd. €
▪ Common Equity Tier 1-Quote1): 11,68 %
München
Stuttgart
Frankfurt
Düsseldorf (HQ)
Berlin
Hamburg
Bilaterale
Finanzierung
Konsortial-
finanzierung
Leasing
Advisory
M&A
Corporate Finance
Restrukturierung
Debt AdvisoryDerivate
Institutional Sales
Kredit
Fördermittel
Financial
Markets
Debt Capital Markets
Private Debt
Asset Management

3. Über mich
Torsten Kleiber
Software Architekt, Entwickler, DevOp
Kreditplattform
18 Jahre IKB, 21 Jahre Oracle Erfahrung in
▪PL/SQL
▪Forms & Reports
▪ADF
▪SOA Mediator
▪Architektur & Infrastruktur
▪Fusion Middleware
▪Development Tools
▪Development Lifecycle
3

4. Welche Fehler kann ich mit Unit-Tests in PL/SQL überhaupt finden?
Änderung bestehender Programme
▪ Aufrufparameter
▪ Ausführungspfade
▪ Business-Logik
▪ Wrapper
Änderung des Datenmodells
▪ Umbenennung von Objekten
▪ Referentielle Integrität
▪ NULL / NOT NULL Spalten
▪ %TYPE und %ROWTYPE-Referenzen
▪ DML Ausführungen
Datenbank/Infrastruktur-Patching/-Upgrade
▪ Optimizer
▪ Indizes
▪ Deprecated / Deleted Features
Daten
▪ Änderungen
▪ Mengen
Modifikationen in bereits getesteten Teilen der Software sollen keine neuen Fehler („Regressionen“) verursachen
 Regressionstests = automatisierte Wiederholung von Unit Tests
4

5. Wie sieht eigentlich mein Entwicklungsprozess aus?
Wie viele Entwickler habe ich?
▪ Einzelentwickler
▪ Kleine Teams mit organisatorischer Code-Trennung
▪ Große Teams mit paralleler Codebearbeitung
Welches Wissen haben meine Mitarbeiter?
▪ Sprachen: PL/SQL, Java, Ruby, …
▪ Buildtools: Maven, ANT, Gradle, …
▪ CI, CD Server: Jenkins
▪ DevOps
▪ Verstehe ich den offengelegten Test-Tool-Code?
Muss ich branchen?
▪ wie schnell werden Änderungen abgenommen
▪ Projekteinsätze
- konkurrieren
- werden häufig verschoben
- Einsatz erst zu einem fixen Zukunfts-Termin
▪ nicht fertige Arbeit soll gesichert werden
▪ es soll früh integriert werden
Muss ich oft meinen Code umstrukturieren?
▪ Austausch/Upgrade Tools/Frameworks
▪ Ablösung von Legacy Code
▪ Modularisierung bei Bedarf
▪ Agilität
▪ Architekturänderungen
Diese und andere Kriterien haben Einfluss auf die Nutzung und Auswahl von Test-Tools.
5

6. Nutzwertanalyse: Bewertungskriterien
Unter anderem aus den vorgehenden Betrachtungen ergeben sich folgende Kriterien für die Auswahl bei uns:
Das ist zunächst nur eine Sammlung!
1) https://de.wikipedia.org/wiki/Nutzwertanalyse
6

7. Nutzwertanalyse: Gewichtungsfaktoren
Diese Kriterien gewichten wir nun nach der Wichtigkeit bei uns:
Wichtigste Kriterien für eine Tool-Shortlist sind Kosten, Knowledge und Aktivität.
7

8. Welche Tools gibt es für die Testautomatisierung mit PL/SQL?
Die kostenlosen aktiven PL/SQL-nahen Tools SQL Developer, utPLSQL und ruby-plsql-spec kommen auf unsere
Short List.
8
Tool Kosten Source Architektur Status
Quest Code Tester (Option für
TOAD/SQL Navigator)
Kosten-pflichtig Closed Deklarativ, Repository Aktiv
Allroundautomations PL/SQL
Developer Test Manager
Kosten-pflichtig Closed Deklarativ, Text-Dateien Aktiv
Oracle SQL Developer Frei Closed Deklarativ, Repository Aktiv
utPLSQL Frei Open PL/SQL Packages Aktiv
ruby-plsql-spec Frei Open Ruby Dateien mit PL/SQL Aktiv
DbUnit Frei Open Junit Extension, Java & XML
Dateien
Aktiv
DbFit Frei Open Fitnesse Wiki, HTML Dateien Aktiv
PLUTO Frei Open PL/SQL Object Types & Members Inaktiv
PL/Unit Frei Closed PL/SQL Packages Inaktiv

9. Testszenario für die Short List
▪ Testumgebung aufsetzen (Schema, Datenmodell, Code für vorhandene Tests)
▪ TDD
▪ Anlage eines scheiternden Tests für ein nicht existierenden Test-Objekts
▪ Deaktivierte Tests für nicht existierendes Test-Objekt
▪ Implementieren Test-Routine und dann Test-Objekt
▪ Berechnen einer Annuität:
▪ Die Höhe R der (jährlichen) Annuität eines Kredites mit der Kreditsumme S0 bei einem Zinssatz von i (z. B. 3 Prozent i=0,03)
und einer Laufzeit von n Jahren
▪ Command Line Interface (CLI)
▪ Code Coverage
▪ Optional Continous Integration / Continous Delivery (CI/CD)
▪ Optional (in vorhandenen Tests bereits enthalten): Exceptions testen
▪ Der Source Code ist hier verfügbar: https://github.com/tkleiber/de.kleiber.demos.plsql.testing.unit
▪ Für den Test wurde eine erweiterte OTN Developer Day Virtual Machine benutzt
Diese Tests führen wir für die Tools der Short List aus und bewerten damit unsere Kriterien.
9

10. Oracle SQL Developer: Demo
10

11. Oracle SQL Developer: Installation
Die Installation wirkt nicht überzeugend, erfüllt aber seinen Zweck.
11

12. Oracle SQL Developer: Branch anlegen
12

13. Oracle SQL Developer: Testumgebung aufsetzen
Wir erzeugen ein Schema mit Datenmodell, Testdaten und PL/SQL Ojekten für den Branch.
13

14. Oracle SQL Developer: Test eines nicht existierenden Test-Objekts
… ist nicht möglich, da das Test-Objekt im Wizard ausgewählt werden muss - die Anlage deaktivierter Tests für
nicht existierende Test-Objekte demzufolge ebenfalls nicht.
14

15. Oracle SQL Developer: Implementieren Test-Routinen
… ist erst nach Anlage der Spezifikation des Test-Objekts möglich, dann kann es im Wizard ausgewählt und der
Test parametrisiert werden. Mehr TDD ist nicht erreichbar. Der Test scheitert, da das Testobjekt-Body noch nicht
implementiert ist.
15

16. Oracle SQL Developer: Implementieren Test-Objekt
Der Test ist nach der vollständigen Implementierung des Test-Objekts erfolgreich
16

17. Oracle SQL Developer: Implementieren Test-Suite
Nur der neue Test läuft in der Suite erfolgreich, da das Testschema neu aufgesetzt wurde.
17

18. Oracle SQL Developer: Synchronisieren Test-Suite
Erst nach dem Synchronisieren der bestehenden Tests sind auch diese erfolgreich.
18

19. Oracle SQL Developer: CLI
.. nur für Batchausführung, Export und Import. Die Ergebnisse können nur in GUI angesehen werden oder eigene
Reports auf das Repository müssen erstellt werden.
19

20. Oracle SQL Developer: Code Coverage
 Es wird nur ausgeführter Code gelistet . Das die Testabdeckung eigentlich 100% ist, ist nicht erkennbar.
20

21. Oracle SQL Developer: Versionierung, Branching, Merging
Exporte enthalten Referenzen auf Schemata, Connections und Objekt ID‘s, sie sind also ohne manuelle
Synchronisation nicht transferierbar zwischen Schematas/Instanzen. Ein Branching und diverse CI Szenarien wie
Fresh Schema / Docker etc. sind schwer möglich.
21

22. Oracle SQL Developer: Bewertung (1)
22

23. Oracle SQL Developer: Bewertung (2)
Die Einzelergebnisse werden zu Schulnoten für die Kriterien zusammengefasst.
23

24. ruby-plsql-spec: Demo
24

25. ruby-plsql-spec: Installation
▪ Oracle Enterprise Linux
- Ruby in erforderlicher Version
- https://community.oracle.com/community/server_%26_storage_systems/linux/oracle_linux/blog/2017/04/18/how-to-install-
the-ruby-sdk-for-oracle-bare-metal-cloud-services-on-oracle-linux-6
- sudo yum -y install yum-utils
- sudo yum-config-manager --enable public_ol6_software_collections
- sudo yum install ruby
- ruby –v
- ruby-plsql-spec
- gem install ruby-oci8
- diverse Abhhängigkeiten
- sudo yum install zlib-devel
- gem install ruby-plsql-spec
▪ Windows
- Wrapper
- Emulatoren
- …
Wer nicht ohnehin mit Unix und Ruby arbeitet oder der administrativ restriktiert ist, für den ist das Meistern der
Infrastruktur kaum möglich.
25

26. ruby-plsql-spec: Branch anlegen
26

27. ruby-plsql-spec: Testumgebung aufsetzen
Wir erzeugen ein Schema mit Datenmodell, Testdaten und PL/SQL Ojekten für den Branch.
27

28. ruby-plsql-spec: Test eines nicht existierenden Test-Objekts
… ist über „fail“ möglich. Die Datenbank-Connection wurde per Environment-Variablen im spec_helper.rb
dynamisiert und über test.env für die lokale Entwicklung gesetzt.
28

29. ruby-plsql-spec: Deaktivierte Tests
… sind über „xit“ möglich.
29

30. ruby-plsql-spec: Implementieren Test-Routinen
 … vor der Implementierung des Test-Objekts ist möglich.
30

31. ruby-plsql-spec: Implementieren Test-Objekt
… iterativ solange, bis die Tests erfüllt sind.
31

32. ruby-plsql-spec: Code Coverage
… wird für alle getesteten Testobjekte generiert.
32

33. ruby-plsql-spec: Bewertung (1)
33

34. ruby-plsql-spec: Bewertung (2)
Die Einzelergebnisse werden zu Schulnoten für die Kriterien zusammengefasst.
34

35. utPLSQL: Demo
35

36. utPLSQL: Branch anlegen
36

37. utPLSQL: Testumgebung aufsetzen
Wir erzeugen ein Schema mit Datenmodell, Testdaten und PL/SQL Ojekten für den Branch.
37

38. utPLSQL: Test eines nicht existierenden Test-Objekts
… entweder über ut.fail oder den Aufruf möglich, im letzteren Fall ist die Fehlermeldung allerdings eher verwirrend.
38

39. utPLSQL: Leeres Test Package
… als Hülle für zukünftige Tests bereits testbar.
39

40. utPLSQL: Deaktivierte Tests
… sind über die Annotation %disabled möglich.
40

41. utPLSQL: Aktivieren eines noch nicht implementierten Tests
… führt wie erwartet zu einem Fehler.
41

42. utPLSQL: Implementieren Test-Routinen & -Objekt
… führt iterativ zu erfolgreichen Tests.
42

43. utPLSQL: CLI
Die beiden CLI‘s (über SQL und JDBC) bieten viele „Reporter“ out of the box.
43

44. utPLSQL: Code Coverage
… kann z.B. über die CLI erzeugt werden und für das gesamte Schema ausgegeben werden.
44

45. utPLSQL: Bewertung (1)
45

46. utPLSQL: Bewertung (2)
Die Einzelergebnisse werden zu Schulnoten für die Kriterien zusammengefasst.
46

47. Nutzwertanalyse: Zielerfüllung & Nutzwert
utPLSQL erfüllt am besten unsere Kriterien und wird jetzt bei uns aktualisiert und ausgerollt.
47

48. Maven: Module
Um Globale Definitionen nur einmal abzulegen und die Abhängigkeiten der Maven-Plugins korrekt zu gestalten
wurden mehrere JDeveloper-Projekte mit Maven-Modulen angelegt.
48
Globale Definitionen
Schema anlegen
Datenmodell mit
Liquibase
PLSQL Sourcen
compilieren
utPLSQL Sourcen und
Testausführung
ruby-plsql-spec Sourcen
und Testausführung
Schema löschen

49. Maven: ruby-plsql-spec
… wird über das exec-maven-plugin per CLI aufgerufen.
49

50. Maven: utPLSQL
… wird über das exec-maven-plugin per CLI aufgerufen. Bei der lokalen Entwicklung werden die Formatter für
CI/CD nicht angewendet.
50

51. CI/CD: Configuration as Code - Jenkinsfile
Die Bereitstellung der Testumgebung und die Testausführung wird über Maven gesteuert, die Ergebnisse werden
danach bereitgestellt.
51

52. CI/CD: Dashboard
Im Dashboard (klassisch/Blue Ocean) werden die Ergebnisse pro Branch aggregiert.
52

53. CI/CD – Klassische Stage View Build
In der klassischen Ansicht werden Ergebnisse, Änderungen und Laufzeiten angezeigt.
53

54. CI/CD – Blue Ocean Build
In der Blue Ocean Sicht werden dieselben Daten pro Lauf angezeigt.
54

55. CI/CD – Test Results Übersicht
Pro Lauf (klassisch/Blue Ocean) werden die Testdetails pro Branch angezeigt.
55

56. CI/CD – Test Results Aggregierte Sicht Build
Die Testausführungen für ruby-plsql-spec und utPLSQL werden analog dargestellt und sind nur anhand der Namen
unterscheidbar.
56

57. CI/CD – Code Coverage Report bei neuem ruby-plsql-spec Test
 Der utPLSQL Coverage Report zeigt die Abdeckung des gesamten Schemas an.
57

58. CI/CD – Code Coverage Report Details
… der beiden Reports. Trotz 2 analysierter Zeilen ist die 100% Abdeckung zu sehen.
58

59. Zusammenfassung
Fazit
▪ Aufgrund der Nutzwertanalyse fällt die Entscheidung bei der IKB für utPLSQL.
▪ Bei anderen Kriterien und Gewichtungsfaktoren kann diese Entscheidung anders ausfallen.
▪ Erforderliche Session-/Datenbank-/Technologie-übergreifende Tests dürften zugunsten ruby-plsql-spec ausschlagen.
▪ utPLSQL war in der Version 2 bereits im Einsatz, die Version 3 ist aber komplett neu.
Weiteres Vorgehen
▪ Implementierung in den Entwicklungsablauf der IKB Kreditplatform inclusive
▪ Continouos Integration
▪ Branching
▪ Code Coverage
▪ Erneute Analyse der Laufzeiten im produktiven Umfeld
▪ Migration der utPLSQL Version 2 Tests
▪ Herausforderung: über 1500 PL/SQL Objekte mit 1 Million LoC
Offene Anforderung
▪ Parametrisierung von Tests mit Testdaten
▪ Test private Package Konstrukte mit Conditional Compile
▪ Testparallelisierung wegen Laufzeiten
▪ Mutation Testing
59

60. Fragen & Antworten
60