Pentaho Kettle und Integrationstests

Für unser Projekt verwenden wir seit kurzem Kettle für ETL-Zwecke. Pentaho Kettle bietet ein UI-basiertes Tool. Anfangs braucht man eine gewisse Zeit, um sich an die Kettle-Benutzeroberfläche zu gewöhnen, da es schwierig ist, sich vorzustellen, wie man die verfügbaren Kettle-Schritte zur Lösung eines Geschäftsproblems orchestriert. Sobald Sie wissen, wie man es benutzt, geht es nur noch darum, einen Schritt per Drag & Drop zu ziehen und ihn mit der verfügbaren Benutzeroberfläche zu konfigurieren. Aus unserer Erfahrung heraus haben wir festgestellt, dass es ziemlich einfach ist, 90 % der Dinge einfach zu gestalten, aber die restlichen 10 % erfordern eine Menge Recherche und am Ende einige Hacks, die uns nicht gefallen haben. Als wir die Kettle-Transformationen und -Aufträge erstellten, waren wir uns nicht ganz sicher, wie es mit der Testbarkeit aussieht. Nach einigen Recherchen fanden wir heraus, dass wir die in der Kettle-Distribution verfügbare Klasse BlackBoxTests für Testzwecke verwenden können. Die Grundlagen dafür sind recht einfach. Sie übergeben einige Eingaben und definieren die erwartete Datei und in der Ausgabe erhalten Sie die tatsächliche Ausgabedatei nach Ausführung der Kettle-Transformation. BlackBoxTests prüft, ob die erwartete Datei mit der tatsächlichen Datei übereinstimmt. Wenn Sie also zum Beispiel eine Sample.ktr testen, erwartet BlackBoxTests Sample.expected.txt/xml/csv als erwartete Datei und Sample.actual.txt/xml/csv als tatsächliche Datei, damit sie funktioniert. Es testet alle verfügbaren Transformationen in einem Ordner und Unterordnern. Per Definition verwendet Kettle kettle.properties (verfügbar im Ordner $HOME/.kettle), was das Testen erschwert. Sie sollten jedoch in der Lage sein, eine Kettle-Transformation isoliert zu testen. Deshalb wollten wir anstelle von kettle.properties eine anwendungsspezifische Eigenschaftsdatei verwenden und diese mit der verfügbaren injectVariables()-Methode an die TransMeta-Klasse übergeben. Wir waren einigermaßen erfolgreich, fanden aber später heraus, dass Kettle immer noch kettle.properties verwendet, auch wenn wir eine andere Eigenschaftsdatei verwenden. Nach einer Menge Debugging haben wir den Schuldigen gefunden. BlackBoxTests verwendet EnvUtil.environmentInit() und erledigt den ganzen Zauber. Es lädt standardmäßig die kettle.properties und zu unserem Entsetzen lädt es in java.lang.System. Wir sind die Verwendung von EnvUtil schnell losgeworden, haben aber erneut festgestellt, dass es nicht ausreicht, die Eigenschaften von außen zu übergeben. Es funktioniert zwar für die aktuelle Transformation, aber irgendwie ist Kettle nicht in der Lage, diese Eigenschaften an eingebettete Subtransformationen zu übergeben. Zuvor funktionierte es nur, weil EnvUtil.environmentInit() Eigenschaften in java.lang.System lädt. Insgesamt waren wir zwar in der Lage, die Tests mit BlackBoxTests mit einigen Hacks isoliert durchzuführen, aber wir kamen zu dem Schluss, dass der Kettle-Code nicht darauf ausgelegt ist, testbar zu sein, und dass er als Legacy-Code in Michael Feathers Sprache bezeichnet werden kann.