Unit-Tests für JBF-Services Gert Lormes, AEW6TA | JBFOne 2009

Ziel dieses Vortrags Sensibilisierung für Unit-Tests von Serverkomponenten Vorstellung der Framework-Unterstützung für Transaction Services (TSe) Hinweise für Data Services (DSe) Hinweise für Application Services (ASe) Wartbarkeit von Tests und Codeabdeckung

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

Warum überhaupt den Server testen? Serverkomponenten haben einen höheren Qualitätsanspruch Server ist kritischer als Client werden oft von mehreren Clientkomponenten genutzt Bediener kann keine Fehler umgehen Serverkomponenten leben typischerweise länger als Clientkomponenten haben damit auch längere Wartungsintervalle Investitionen in Wartbarkeit lohnen sich (noch) mehr

Warum den Server nicht einfach über den BAP testen? Client Code ist eventuell noch nicht fertig Aufwand zur Durchführung zu hoch: Tomcat starten, Anmeldung, … zu viele Abhängigkeiten es ist sehr schwer, die Testumgebung passend zum Test aufzusetzen nicht alle Testfälle sind über Service-Schnittstelle ausführbar Asserts sind über Service-Schnittstelle nicht ausreichend möglich Regressionstests praktisch nicht möglich  Tests müssen Standalone als Unit-Tests laufen!

Was testen wir am Server Datenbankzugriffe Data Services Hostzugriffe Transaction Services Business-Logik Application Services  DSe, TSe und ASe sind eigene Einheiten (= Units) und deshalb natürliche Kandidaten für Unit-Tests

Forderungen: Tests sollen … automatisiert und schnell laufen (Regressionstests) wenn möglich, isoliert laufen bei DB-Zugriffen ist das möglich IMS-Transaktionen??? eine hohe Aussagekraft haben mit vernünftigem Aufwand erstellbar sein gut wartbar sein „iMove-kompatibel“ sein

Ablaufumgebung Test mit BAP Entwicklertest BAP Eclipse Test- treiber Tomcat AS TS DS DS TS

Zu beachten  Frameworkunterstützung erforderlich! ClientContext Preferences Configuration Controlapi … Leider können sich die Details mit jedem JBF-Release ändern  Frameworkunterstützung erforderlich!

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

Basics: ein TS … public class MyRequest implements Serializable {...} public class MyResponse implements Serializable {...} public class MyTs extends AbstractTS { public AttributeList invoke(AttributeList attRequest) { // auspacken DefaultServiceRequest dsRequest = (DefaultServiceRequest) AbstractApplicationService.getRequestFromAttributeList(attRequest)); MyRequest request = (MyRequest) dsRequest.getData(); // erstelle InputMessages, rufe Host-Tx, erstelle Response aus OutputMessages MyResponse response = ...; // einpacken DefaultServiceResponse dsResponse = new DefaultServiceResponse(response); AttributeList attResponse = AbstractApplicationService. getResponseAsAttributeList(dsResponse); return attResponse; } }

… und ein rufender AS public class MyAs extends AbstractService implements ServiceCommand { … MyRequest request = ...; ServiceRequest dsRequest = new DefaultServiceRequest("TsName", request); ServiceResponse dsResponse = super.executeTransactionService(dsRequest); MyResponse response = (MyResponse) dsResponse.getData(); ... } AbstractService.executeTransactionService() verpackt den DefaultServiceRequest in eine AttributeList ermittelt aus dem Namen (hier: "TsName") und der Datei <xxxHostObject.ini> die TS-Klasse instanziiert den TS und ruft ihn auf packt aus der AttributeList den DefaultServiceResponse aus  Das ist im Test nachzubilden!

Idee eines Testtreibers public class MyTest extends TestCase { public void testCase1() { MyRequest request = new MyRequest(); // request initialisieren … MyTs ts = new MyTs(); String tsName = "TsName"; MyResponse response = (MyResponse) execute(request, ts, tsName); // und hier kommen die asserts ... } public void testCase2() {…} private Serializable execute(Serializable request, AbstractTS ts, String tsName) { DefaultServiceRequest dsRequest = new DefaultServiceRequest(tsName, request); AttributeList attRequest = AbstractApplicationService.getRequestAsAttributeList(dsRequest); AttributeList attResponse = ts.invoke(attRequest); DefaultServiceResponse dsResponse = (DefaultServiceResponse) AbstractApplicationService.getResponseFromAttributeList(attResponse); return dsResponse.getData();

Aber … So einfach geht das leider nicht, denn … dieser Test wird scheitern wegen Anmeldung Konfiguration Datenbankverbindungen Technische User …

… deshalb Unterstützung aus dem Framework AbstractImsconTestCase extends TestCase { … } mit JBF 7.15 (BAP 4.0) verfügbar enthält die bereits gezeigte execute-Methode stellt in setUp() die benötigte Umgebung her räumt in tearDown() wieder auf

Funktionierender Testtreiber public class MyTest extends AbstractImsconTestCase { // setUp() und tearDown() sind optional; wenn vorhanden, // müssen sie als Erstes bzw. Letztes ihre super-Methoden rufen! protected void setUp() throws Exception { super.setUp(); … } protected void tearDown() throws Exception { super.tearDown(); public void testCase() { MyResponse response = (MyResponse) super.execute(request, ts, tsName); ...

AbstractImsconTestCase – 1 baut in jedem setUp() den ClientContext auf ruft dazu getRzbkForTest(), getUseridForTest() und getBedienernrForTest() diese haben Defaults, können aber überschrieben werden außerdem im Angebot: overwriteClientContext(String userid, String bedienernr) überschreibt die GENO Userid und die Bedienernummer RZBK bleibt z. B. für Testfälle im Zusammenhang mit dem 4-Augen-Prinzip stellt in jedem tearDown() den alten ClientContext wieder her Integration in Baselibs geplant Kontextdaten in local.setup.properties

AbstractImsconTestCase – 2 allgemeine JBF-Einstellungen: diese sind für alle Arten von Standalone Unit-Tests erforderlich: System Properties für diverse Factories einige weitere Einstellungen Einstellungen für ImsConnect: diese sind speziell zum Test für TSe erforderlich Sicherstellen, dass die Implementierung „JBFImsConnect“ benutzt wird Setzen eines Default-Loggers Setzen einer Default-Konfiguration für IMSU (normalerweise wird die Konfiguration mittels Steuer-API aus Oracle gelesen)

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

HcRuntime oder HDS? Standalone Tests waren bisher nur mit HcRuntime möglich dazu wurde ein Test-Jar aus CBx benutzt (template-service-test) die Test Cases mussten sich von HcStandaloneTestCase ableiten dahinter lief bereits ein einfacher ImsConnect Client in Java ab Jetzt können (fast) alle IMS-Transaktionen unabhängig von der Implementierung des TS standalone getestet werden Ausnahmen: 3-stellige Transaktionscodes in BAP 4.0: einige weitere Sonderfälle, z.B. NIB-Transaktionen

Testtreiber für HcRuntime Zusatzanforderung bei HcRuntime: Request und Response sind Interfaces erben von HcRequest oder HcResponse deshalb: Erzeugen einer Request-Instanz über BeanImplProvider public interface MyRequest extends HcRequest {…} public interface MyResponse extends HcResponse {…} public class HcRuntimeTestSample extends AbstractImsconTestCase { public void testCase() { MyRequest request = (MyRequest) BeanImplProvider. createImplementationFor(MyRequest.class); // request initialisieren … MyTs ts = new MyTs(); MyResponse response = (MyResponse) super.execute(request, ts, "TsName"); // asserts … } }

Anwendungsfall: Migration von HDS nach HcRuntime HcRuntime ist das offizielle Framework der FIDUCIA zur Implementierungen von TSen performant Anwendungen sind einfach zu entwickeln und zu warten Unterstützung von Redefines, Occurs usw. Viele TSe sind aber noch in HDS (oder anderen Techniken) implementiert Umstellung auf HcRuntime war bisher sehr riskant, da kaum testbar (never change a running system) dieses K.o.-Kriterium entfällt jetzt

Testen bei der Migration von HDS nach HcRuntime Erstelle neue Request- und Response-Interfaces, die strukturell den Request- und Response-Klassen der alten Implementierung gleichen (Eclipse: „Refactor / Extract Interface…“) von HcRequest oder HcResponse erben bringe ausreichend viele Testfälle für die alte Implementierung zum Laufen Positiv- und Negativ-Fälle berücksichtigen hohe Codeabdeckung erzielen Erstelle neue Implementierung mit HcRuntime Die Testfälle sind für beide Implementierungen verwendbar

Migration von HDS nach HcRuntime: Muster interface NewRequest extends HcRequest {…} interface NewResponse extends HcResponse {…} class OldRequest implements Serializable, NewRequest {…} class OldResponse implements Serializable, NewResponse {…} Alte Implementierung: arbeitet unverändert mit OldRequest, OldResponse Neue Implementierung: arbeitet mit NewRequest, NewResponse Test Cases: arbeiten mit NewRequest, NewResponse Ausnahme: Instanziierung mit „new OldRequest()“ statt mit BeanImplProvider TS-Klasse über Factory erzeugen  einfaches Umschalten alt / neu

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

Test von Data Services JBFOne 2007 Unit-Tests entwickeln und Testabdeckung messen in HORIZON-Projekten Data Services sollen in einer isolierten Umgebung getestet werden eigenes Schema benutzen für jeden Testfall exakt die benötigten Daten einstellen Helperklassen liegen (noch) in horizonbaseutils https://svn.fiducia.de/svn/horizon_utils/trunk/horizonbaseutils setUp- und tearDown-Code sowie Asserts gehören nicht in die Transaktionsklammer des Data Services

Test von Data Services Implementierung von setUp-Code alles muss lesbar im Java Code stehen pro Testcase exakt die benötigten Daten einstellen keine Excel-Files verwenden „zu Fuß“ über JDBC Fachlicher Code Delegation an Helperklassen mit sprechenden Klassen- und Methodennamen kein „Verstecken“ im setUp() der eigenen Klasse oder gar von Oberklassen Fingerspitzengefühl erforderlich beim Abwägen zwischen Auscodieren im Testcase Nachteil: Code-Duplizierung  Test wird evtl. zu lang und unübersichtlich Delegation an Helpermethoden Nachteil: Transparenz kann verloren gehen  aussagekräftige Namen verwenden, z.B. erstelleKontoOhneIndividualKonditionen()

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

Application Services Wichtig Tests für ASe testen den AS-Code die TSe und DSe sind (hoffentlich) schon getestet!!! Korrektheit von serviceRegistry und ServiceDeskriptoren testen? dafür sind keine eigenen Unit-Tests erforderlich Tool vorhanden (Sotograph) Viele Application Services sind trivial sie rufen nur einen TS oder DS auf sie geben den Client Request 1:1 an diesen weiter für diese Application Services reicht jeweils ein Unit Test

Application Services Komplexer werden Tests für ASe, wenn mehrere TSe und DSe aufgerufen werden zusätzlich ASe aus anderen Modulen aufgerufen werden (z.B. CBx, Kunde, …) Business-Logik enthalten ist Was soll getestet werden? die eigene Business-Logik Die Ergebnisse der Aufrufe an TSe, DSe, andere ASe müssen dazu reproduzierbar sein Test-Dubletten verwenden!? Leider: für den Test von ASen gibt es noch keine Best Practices

Agenda Motivation Transaction Services HDS und HcRuntime Data Services Application Services Qualität von Unit-Tests

Qualität von Unit Tests Es genügt nicht, dass die Unit-Tests im Eclipse grün sind! Qualitätskriterien sind hohe Codeabdeckung ausreichend viele assert-Statements korrekte assert-Statements Wartbarkeit der Tests Ob ausreichend viele und korrekte assert-Statements codiert sind, lässt sich kaum messen  Produktspezialisten einbeziehen Aber: zur Messung der Codeabdeckung gibt es Werkzeuge In mehreren Projekten eingesetzt: Cobertura http://cobertura.sourceforge.net

Was ist Cobertura? Cobertura ist ein freies Java-Tool das die Codeabdeckung von Java-Programmen durch Tests misst Features instrumentiert den Java Bytecode berechnet die prozentuale Abdeckung von Codezeilen und von Branches berechnet die McCabe-Metrik (= zyklomatische Komplexität) erzeugt HTML Reports, über die bis auf Quellcode-Ebene navigiert werden kann per Konfiguration können Packages oder Klassen von der Messung ausgenommen werden (z. B. generierte Klassen, Testklassen) Nutzen Cobertura hilft bei der Identifikation von Programmteilen, die nicht durch Tests abgedeckt werden Toter Code? fehlende Tests?

Cobertura Report – Projekt- und Package-Ebene

Cobertura Report – Klassenebene

Wartbarkeit von Unit-Tests Unit-Tests machen eine erhebliche Menge des Gesamtcodes aus (50% !?) ihre Erstellung kostet erheblichen Aufwand gute Wartbarkeit ist ein Muss Maßnahmen Zusammenfassung zu Suites rekursiv eine Top-Level Suite pro Produkt oder Komponente diese (und nur diese) als Launcher mit sprechendem Namen in SVN einchecken Tests müssen schnell laufen (im Sekundenbereich) vor jedem nichttrivialen SVN-Commit laufen lassen keine harten Abhängigkeiten zu Userids, DB-Instanzen, … keep it simple – Lesbarkeit ist höchstes Gebot keine eigenen Frameworks und Klassenhierarchien bauen keine 80%-Bedürfnisse in setUp() und tearDown() legen – lieber delegieren keine Excel-Tabellen für setUp() – alles in den Code

Zusammenfassung Serverkomponenten haben einen hohen Qualitätsanspruch Dieser kann nur mit Standalone Unit-Tests erreicht werden Für Transaction Services ab JBF 7.15 / BAP 4.0 möglich Für Data Services schon länger Test von Application Services muss noch besser unterstützt werden Codeabdeckung kann mit Cobertura gemessen werden Übergabekriterium zwischen AEW3 und AEW4/AEW5?

Fragen? – Diskussion? Gert Lormes Anwendungsentwicklung Technische Architektur Gert.Lormes@fiducia.de 0721/4004-1669

Ihr IT-Partner Vielen Dank