Unit-Tests AEM 6.1 und spöttische Schlinge, Jcr und OSGi

Question

Hintergrund

Hallo,

So bin ich vor kurzem bei einer Firma beginne AEM mit 6.1 und ich bin auch ein Junior-Entwickler.

Wenn ich mit meinem Kumpel (leitender Entwickler) zusammen bin, fährt er normalerweise. Aber schreibt keine Unit Tests, das nervt mich. Er hat erklärt, dass es schwierig ist, AEM zu testen.

Unser Projekt verwendet HTTP-Anfragen und Antworten, das Osgi-Framework und ein großes Jcr-Repository, jsps, Servlets und Datenbankverbindungen. Wir verwenden alle möglichen Designmuster, erstellen Adapterklassen ... Und so weiter.

Fragen

Warum ist es schwierig, Unit-Tests für AEM, zu schaffen, wenn es sind Frameworks für Schleuder, OSGi und Jcr verspotten?

Wie kann ich Unit Test 6.1 lernen?

voran ...

Ich bin auf der Suche nach Ressourcen Unit-Tests für AEM in der Lage sein zu schaffen? Wenn möglich, können Sie unter den folgenden Ressourcen verlinken?

Answer 1

Ich fühlte den gleichen Weg, als ich begann, in AEM zu entwickeln. Mit der Zeit habe ich versucht, das für meine Firma zu ändern, und jetzt haben wir eine Umgebung, in der wir unseren AEM-Code testen.

Warum ist es schwierig, AEM-Code zu testen? Ich denke, die Hauptgründe auf 2 Punkte herunterkochen:

1. Viele Adobe-Beispiele kommen in Form von JSPs mit Inline-Java-Code (Scriptlets). Skriptcode ist nicht testbar und auch nicht wiederverwendbar. Ich denke, ein Grund, warum Sie das von Adobe so sehr sehen, ist, dass das Produkt es Entwicklern ermöglicht, die Basisfunktionalität zu "überlagern". Eingebauter Code läuft unter "libs", aber Entwickler können Code in libs kopieren und in "apps" platzieren und dann ändern - und diese Änderungen werden anstelle des vorhandenen Codes wirksam. Mit JSPs, die Scriptlets enthalten, ist es einfach, Code wie diesen zu ersetzen, weil Sie das Markup zusammen mit dem Java-Code erhalten und immer noch ändern können. Aber wenn dieser Java-Code in einer anderen Bibliothek war, wie könnten Sie ihn ersetzen? Obwohl es möglich wäre, wäre es viel schwieriger. Also ich denke, Adobe hat eine Menge Beispielcode, der Java-Code in Scriptlets zeigt. Aber das ist schlechte Praxis, ungeachtet der Gründe dafür. Sie können das nicht tun, wenn Sie einen Komponententest durchführen möchten. Also lass es nicht zu. Entwickler müssen Code in .java-Klassen einfügen und ihn über Tags (oder andere ähnliche Mechanismen) einfügen. Dann können Sie den Code testen und ihn leichter wiederverwenden.
2. Der meiste Code, den Sie für AEM schreiben, muss mit dem von AEM verwendeten Repository interagieren.Sie haben also zwangsläufig Abhängigkeiten zu Code/Paketen, die Teil der Basis-AEM-Installation sind. Wenn Sie versuchen, eigene .java-Klassen zu schreiben, stellen Sie schnell fest, dass Dinge nicht kompiliert werden, wenn Sie nicht die gleichen Abhängigkeiten vom Klassenpfad für Ihre IDE haben. Für ältere AEM-Versionen gab es keine vom Hersteller bereitgestellte Möglichkeit, diese Kenntnisse zu erlangen. Aber neuere Versionen haben es - ein "Uber" .jar. Ich denke, Abhängigkeitsprobleme schrecken Entwickler ab. Und sie greifen auf Scriptlets in JSPs für ihren Java-Code zurück. Wenn Sie Ihren AEM-Code testen möchten, müssen Sie alle Abhängigkeiten, die Sie mit dem von AEM bereitgestellten Code haben, extrahieren und als Teil Ihres Projekts in die IDE aufnehmen. Das ist keine triviale Arbeit, sondern Voraussetzung dafür, dass Sie sich in einem IDE- und Continuous Integration Build-Projekt wie in anderen Java-Projekten effizient entwickeln und testen können.

Wir lösten 2 # durch einen „Behälter“ .jar machen, die die .jar-Dateien alle aus unserer AEM-Instanz enthält, die wir benötigen Test Java-Code zu kompilieren und Einheit. Aber neuere AEM-Versionen bieten dies im Uber .jar, was diese Aufgabe sehr erleichtert. Wir verwenden Mockito auch für Unit-Tests von Java-Code. Es ermöglicht einfaches und starkes Spotten der Sling- und AEM-Klassen, auf die wir angewiesen sind. Wir benutzen es die ganze Zeit. Wir verwenden gelegentlich PowerMockito, um etwas zu spotten.

Darüber hinaus ist es nicht schwieriger, Java-Code für die Verwendung in AEM zu testen, als jeden anderen Java-Code zu testen. Wir haben auch JavaScript Unit Testing Support mit Karma und Jasmine hinzugefügt - das gleiche gilt für den clientseitigen Code.

Hier sind einige Ressourcen, die helfen können:

• https://github.com/justinedelson/aem-uberjar-demo
• https://docs.adobe.com/docs/en/aem/6-1/develop/dev-tools/ht-projects-maven.html
• AEM 6.1 Maven Dependency Resolution
• http://www.wemblog.com/2014/07/how-to-include-all-cq-dependencies-in.html
• http://blogs.adobe.com/cqpost/2012/03/19/unit-testing-in-adobedaycq5/
• CQ - Writing Server-side JUnit tests

Answer 2

Es hängt von Code ab, ein Code, den Sie leicht mit Tests abdecken können, wenn andere nicht. Es ist ein großer Schmerz, Komponententests für solchen "nicht testbaren" Code zu unterstützen (Code, der ohne Tests erstellt wurde).

Hier finden Sie Bibliotheken für Unit-Tests link mit Beispielen.

Auch Sie können Ihren Code mit etw wie testen (in vielen Fällen ist es einfacher, Mock mit Mockito zu erstellen, anstatt JCR fixture from JSON file in Sling-Mock-Bibliothek zu erstellen).

Answer 3

Ein großes Problem ist, dass das Uber-Jar verschleiert ist und somit nur die API-Schnittstellen und -Klassen enthält. Als Ergebnis müssen Sie die AEM-Objekte verspotten, was ziemlich umständlich ist. Allerdings gibt es ein UNobfuscated Uber-Glas, das von Adobe zur Verfügung gestellt wird.

Answer 4

Schreiben Tests für AEM sollte nicht schwer sein, bietet die Apache Sling-Community Möglichkeiten zum Testen auf verschiedenen Ebenen und weil AEM auf Sling basiert können wir die gleichen Tools verwenden.

Kasse die Links unten:

• Übersicht: https://sling.apache.org/documentation/tutorials-how-tos/testing-sling-based-applications.html
• Unit Testing: https://adapt.to/2016/en/schedule/unit-testing-with-sling-aem-mocks.html
• HTTP-Prüfung: https://adapt.to/2016/en/schedule/sling-http-testing-framework.html
• Sling Mocks: https://sling.apache.org/documentation/development/sling-mock.html