Testgetriebene Entwicklung (TDD) mit dbt: Erst testen, dann SQL

Testgetriebene Entwicklung mit dbt: Erst testen, dann SQL

Wenn Sie mehr als drei Tage als Analytik-Ingenieur verbracht haben, hatten Sie wahrscheinlich schon einmal diesen Moment: Ihr dbt-Modell läuft, aber die Zahlen sehen... daneben aus. Nicht kaputt, aber seltsam genug, um Sie an Ihren Lebensentscheidungen (oder zumindest an Ihrem SQL) zweifeln zu lassen. Der Code funktioniert, aber die Daten? Nicht so sehr. Und seien wir ehrlich, die meisten dieser "Überraschungen" beginnen mit dem Klassiker: "Ich bringe das mal schnell in Ordnung." Eine Woche später sind Sie dabei, ein Chaos zu entwirren, das Spaghetti neidisch machen würde. Bei der Sicherstellung der Qualität des Datenmodells geht es nicht nur darum, dass die Tests bestehen oder Ihr Code läuft. Es geht darum, sicherzustellen, dass Ihre Daten tatsächlich nützlich und vertrauenswürdig sind und Ihnen nicht ein passiv-aggressives Slack von Ihren Stakeholdern einbringen.

Das Schöne an dbt ist, dass die Tests bereits integriert sind. Sie haben Ihre not_null Tests, Ihre unique Tests und sogar einige ausgefeilte Unit-Tests. Aber jetzt wird es interessant: Was wäre, wenn Sie diese Tests schreiben würden, bevor Sie Ihr Modell schreiben? Was wäre, wenn Sie zunächst definieren würden, wie "gut" für Ihre Daten aussieht, und dann Ihre Transformation so gestalten würden, dass sie diese Erwartungen erfüllt? Das ist TDD für dbt. Anstatt ein Modell zu erstellen und zu hoffen, dass es funktioniert, definieren Sie zuerst die Regeln und erstellen dann das Modell, das diesen Regeln folgt.

Was ist testgetriebene Entwicklung (TDD)?

Testgetriebene Entwicklung (TDD) ist das Äquivalent zur Softwareentwicklung, wenn Sie die Prüfungsfragen schreiben, bevor Sie die Klasse unterrichten. Die Idee ist einfach: Sie beginnen damit, einen Test zu schreiben, der beschreibt, was Ihr Code tun soll, sehen zu, wie er fehlschlägt (weil Sie den Code noch nicht geschrieben haben), und schreiben dann gerade genug Code, um den Test zu bestehen. Spülen und wiederholen. Es ist ein bisschen so, als würden Sie Fallen für Ihr zukünftiges Ich aufstellen - nur dass Sie nicht in eine Grube fallen, sondern Fehler abfangen, bevor sie in die Produktion gelangen. TDD zwingt Sie dazu, sich im Vorfeld Gedanken über die Anforderungen zu machen, sorgt für Ehrlichkeit und gibt Ihnen ein gutes Gefühl (oder zumindest weniger Angstschweiß), wenn Sie Ihren Code refaktorisieren oder neue Funktionen hinzufügen.

Wenn Sie jetzt denken: "Moment mal, das klingt so ähnlich wie das, was ich im dbt machen sollte", dann haben Sie völlig recht. Analytics Engineering ist nichts anderes als Software-Engineering mit mehr SQL und weniger Memen über JavaScript-Frameworks. In beiden Welten wollen Sie Probleme frühzeitig erkennen, Ihre Leitplanken automatisieren und sicherstellen, dass Ihre Arbeit nicht in dem Moment kaputt geht, in dem jemand anderes sie anfasst. Bei TDD in dbt geht es darum, die Tests zu schreiben, die "gute Daten" definieren, bevor Sie das Modell erstellen, so dass Sie nicht im Ungewissen gelassen werden, wenn es an der Zeit ist, es einzusetzen.

Kurz gesagt: TDD für Analytikingenieure bedeutet, dass Sie nicht mehr hoffen, dass Ihre Modelle funktionieren, sondern wissen, dass sie funktionieren. Sie schreiben die Tests, die den Erfolg definieren, und erstellen dann Ihre TDD-Modelle so, dass sie diese Tests bestehen. Das ist zwar etwas mehr Arbeit, aber es zahlt sich jedes Mal aus, wenn Sie eine Änderung vornehmen und Ihre Tests ein Problem erkennen, bevor Ihr Chef (oder noch schlimmer, Ihr Kunde) es tut.

Testen in dbt: Überblick

Wir wissen natürlich, dass dbt über eingebaute Tests verfügt. Aber nur ein paar dbt-Tests hinzuzufügen ist nicht das, was ich unter testgetriebener Entwicklung (TDD) verstehe. Sehen Sie, die Tests von dbt sind meistens Datentests, d.h. sie testen die Gültigkeit Ihrer Daten Zeile für Zeile. Was wir testen wollen, ist die Logik Ihrer Modelle. Vor nicht allzu langer Zeit hat dbt eine Funktion für Unit-Tests herausgebracht, die zumindest einen Teil dessen erfüllt, was wir für einen testgesteuerten Arbeitsablauf benötigen. Aber wir brauchen mehr als das. Werfen wir einen Blick auf alle Arten von Tests, die wir benötigen, um einen testbasierten Entwicklungsworkflow zu erstellen.

Es ist leicht, sich in dbt-spezifischen Begriffen wie 'generisch' oder 'benutzerdefiniert' oder 'Datentest' zu verlieren, aber es ist gut, ein konzeptionelles Verständnis davon zu haben, was und warum Sie eigentlich testen, bevor Sie darauf eingehen , wie Sie es testen. Ich unterscheide gerne grob zwischen diesen Testbereichen: einspaltig zeilenweise, mehrspaltig zeilenweise, vollständig modelliert/aggregiert, Modell-Unit-Tests, Makro-Unit-Tests und Modellverträge. Nicht alle diese Bereiche werden von Haus aus unterstützt, aber mit ein wenig Zauberstaub können wir sie zum Laufen bringen.

Einzelspaltentests Zeile für Zeile

Einzelspaltentests, die Zeile für Zeile durchgeführt werden, helfen Ihnen zu verstehen, ob in einem der Werte einer einzelnen Spalte etwas falsch ist. Dies ist jeder Test, den Sie in eine bestimmte Spalte in der YAML-Datei Ihres Modells eingeben. Es handelt sich dabei um die grundlegenden, sofort einsetzbaren dbt-Tests wie unique und not_null, aber auch um fortgeschrittenere Tests aus anderen Paketen. Mit dbt_utils.not_empty_string können Sie zum Beispiel testen, dass die Spalte keine leeren String-Werte enthält (z.B. ''). Natürlich können Sie auch Ihre eigenen benutzerdefinierten, einzigartigen Tests erstellen, indem Sie sie einfach zum Ordner tests hinzufügen und dafür sorgen, dass eine Zeile zurückgegeben wird, wenn eine Zeile einen Fehler aufweist.

# Single column row-by-row example
models:
  - name: my_model
    columns:
      - name: first_column
        tests:
          - unique

Mehrspaltige Tests Zeile für Zeile

Diese Tests helfen Ihnen zu verstehen, ob in einer der Zeilen mit einer Kombination von Spalten etwas nicht stimmt. Einer der am häufigsten verwendeten Tests für dieses Szenario ist dbt_utils.unique_combination_of_columns, um auf einfache Weise zu prüfen, ob es doppelte Zeilen gibt, die einen Ersatz-Primärschlüssel verwenden, der den Wert mehrerer Spalten kombiniert. Auf den ersten Blick scheint die Eindeutigkeit zu bedeuten, dass wir es mit dem gesamten Modell zu tun haben und nicht mit einem zeilenweisen Wert. Wir müssen uns jedoch darüber im Klaren sein, dass wir damit nach Duplikaten auf einer zeilenweisen Basis suchen und nicht nach einer Aggregation, wie z.B. dem Testen der Summe einer Reihe von Zeilen. Und es gibt viele andere mehrspaltige Tests. Mit dbt_utils.expression_is_true können Sie z.B. die Gültigkeit eines SQL-Ausdrucks über mehrere Spalten hinweg testen, wie eine Berechnung mit Zahlen oder eine Textfunktion.

# Multi-column row-by-row example
models:
  - name: my_model
    tests:
      - dbt_utils.expression_is_true:
          expression: "sales_empire + sales_rebellion = total_sales_galaxy"

Vollständige Modelltests und Aggregationstests

Vollständige Modelltests und Aggregationstests ermöglichen es Ihnen zu prüfen, ob etwas über verschiedene Modelle oder über eine Reihe von Zeilen im Modell hinweg falsch ist. Diese Tests unterscheiden sich von den zeilenweisen Tests in dem Sinne, dass sie mehrere Zeilen gleichzeitig für den Test verwenden. Ein Beispiel hierfür ist der dbt_utils.cardinality_equality Test, der die unterschiedlichen Werte einer Spalte mit den unterschiedlichen Werten einer anderen Spalte in einem anderen Modell vergleicht. Ein Aggregationstest prüft Ihre Annahmen für ein Modell, das auf einer Berechnung über mehrere Zeilen basiert, z.B. eine minimale oder maximale Zeilenzahl oder die Behauptung, dass die normalisierten Werte über ein Jahr die Summe 1 ergeben. Der Aggregationstest ist sehr leistungsfähig, wird aber in dbt-Projekten oft nicht ausreichend genutzt.

# Full model aggregation example
models:
  - name: my_model
    tests:
    - dbt_expectations.expect_column_distinct_count_to_equal:
        value: 10
        group_by: [my_categories_column] 

Modellieren Sie Einheitstests

Mit Modell-Unit-Tests können Sie testen, ob die (Geschäfts-)Logik in einem bestimmten Modell korrekt ist, indem Sie sicherstellen, dass eine bestimmte Eingabe eine bestimmte Ausgabe liefert. Und das Gute daran: Sie brauchen dazu nicht einmal Ihre tatsächlichen Daten! Unit-Tests sind großartig, denn sie ermöglichen es Ihnen, die Eingabe mehrerer Referenzen zu simulieren und eine beliebige Anzahl von Zeilen zu erwarten, die alle Arten von Operationen in Ihrem Modell ermöglichen. Wenn Sie die eingebauten Makros wie {{ dbt.current_timestamp() }} intelligent nutzen, können Sie ganz einfach sicherstellen, dass dynamische Logik, wie z.B. 'letzte 30 Tage', mit festen Daten durch eine Überschreibung getestet werden kann.

unit_tests:
  - name: test_has_valid_end_date
    description: "Check that the contract end date is the last date of the month for any given cancellation date"
    model: dim_customers
    overrides:
      macros:
        current_timestamp: "'2025-01-03 00:00:00.000 +0200'::timestamp"
    given:
      - input: ref('stg_customers')
        rows:
          - {id: 1, cancellation_date: "2025-01-02"}
          - {id: 2, cancellation_date: "2025-01-03"}
          - {id: 3, cancellation_date: "2025-01-04"}
          - {id: 3, cancellation_date: null }

    expect:
      rows:
          - {id: 1, contract_end_date: "2025-01-31"}
          - {id: 2, contract_end_date: "2025-01-31"}
          - {id: 3, contract_end_date: "2025-01-31"}
          - {id: 4, contract_end_date: null }

Makro-Einheitstests

Unit-Tests für Makros sind eine Möglichkeit zu testen, ob die Eingabe eines Makros die erwartete Ausgabe liefert. Da Makros häufig modellübergreifend verwendet werden, ist die Möglichkeit, ihre Konsistenz zu testen, von entscheidender Bedeutung, um nachts ruhig schlafen zu können, d.h. um sicherzustellen, dass Ihre Datenpipeline nicht zusammenbricht, wenn Sie es am wenigsten erwarten. Makros können nicht standardmäßig getestet werden, aber es gibt einfache Möglichkeiten, um Ihr dbt-Makro zu testen.

Muster-Verträge

Modellverträge sind die Art und Weise, wie dbt genau festlegt, was Ihre Modelle ausgeben sollen. Betrachten Sie sie als das Kleingedruckte in Ihren Datenvereinbarungen. Sie ermöglichen es Ihnen, die erwarteten Spalten, Typen und Einschränkungen zu definieren. Wenn also jemand versucht, eine unzulässige Änderung einzuschmuggeln, wird er durch den Vertrag in die Pfanne gehauen (oder zumindest Ihr Build scheitert). Aber hier wird der Modellvertrag erst richtig interessant: Er validiert Ihre Daten nicht nur, nachdem sie erstellt wurden, wie es normale Tests tun. Stattdessen erzwingen sie Einschränkungen auf der Datenbankebene während des Erstellungsprozesses selbst. Wenn Sie einen Modellvertrag mit enforced: true definieren, nimmt dbt Spaltennamen, Datentypen und Einschränkungen in die DDL-Anweisungen auf, die es an Ihre Datenplattform sendet. Das bedeutet, dass die Datenbank selbst diese Regeln durchsetzt, nicht nur Ihr dbt-Projekt.

Für TDD-Workflows ist dies ein entscheidender Vorteil. Anstatt zuerst Ihr Modell zu schreiben und dann zu hoffen, dass Ihre Tests Probleme erkennen, definieren Sie den Vertrag im Voraus. Das Modell wird gar nicht erst erstellt, wenn es nicht mit der erwarteten Struktur übereinstimmt. Dies zwingt Sie dazu, Ihre Datenanforderungen zu durchdenken, bevor Sie eine einzige SQL-Zeile schreiben - und genau darum geht es bei TDD. Und da die Einschränkungen auf Datenbankebene durchgesetzt werden, erhalten Sie eine bessere Leistung (Sie müssen keine separaten Testabfragen ausführen) und eine bessere Garantie dafür, dass die Regeln der Datenintegrität tatsächlich eingehalten werden.

Anwendung der TDD-Prinzipien im dbt

Wie wenden Sie TDD also tatsächlich auf Ihren dbt-Workflow an? Der Schlüssel liegt darin, Ihren üblichen Prozess auf den Kopf zu stellen. Anstatt ein Modell zu schreiben und dann Tests hinzuzufügen, um es zu validieren, beginnen Sie damit, zu definieren, wie Erfolg aussieht. Das mag zunächst kontraintuitiv klingen - denn wie können Sie etwas testen, das noch nicht existiert? Aber genau das ist der Punkt. Sie testen nicht das Modell, sondern Sie definieren die Anforderungen, die das Modell erfüllen soll.

Beginnen Sie mit dem Ziel vor Augen. Wie sehen "gute" Daten für Ihren Anwendungsfall aus? Sollten bestimmte Spalten niemals Null sein? Sollte es genau eine Zeile pro Kunde geben? Soll die Summe aller Verkäufe dem Gesamtumsatz entsprechen? Dies sind Ihre Testanforderungen. Schreiben Sie sie zuerst auf, bevor Sie eine einzige SQL-Zeile schreiben. Dies zwingt Sie dazu, Ihre Geschäftslogik und die Anforderungen an die Datenqualität im Voraus zu durchdenken, und genau dafür ist TDD ja gedacht.

Beispiel: Zeilenzahltest vor der Modellerstellung

Nehmen wir an, Sie erstellen ein Modell, das Daten über Nutzerbeschwerden sammelt. Vielleicht möchten Sie auch keine Probleme im Zusammenhang mit der ersten Charge Ihres Produkts betrachten. Bevor Sie das Modell schreiben, können Sie definieren, wie "angemessen" aussieht. Das Paket dbt-expectations bietet eine Reihe von Tools für die Implementierung dieser Art von Aggregationstests.

So könnten Sie zunächst Ihre Testanforderungen definieren:

models:
  - name: daily_problems_summary
    tests:
      - dbt_expectations.expect_table_row_count_to_be_between:
          min_value: 1
          max_value: 99
          group_by: "problems"
          row_condition: "batch != 1"

Sie schreiben diesen Test, bevor Sie das Modell erstellen. Wenn Sie ihn ausführen, wird er fehlschlagen (weil das Modell noch nicht existiert), aber das ist genau das, was Sie bei TDD wollen. Der Fehlschlag des Tests sagt Ihnen, was Sie bauen müssen. Das Schöne an diesem Ansatz ist, dass er Sie zwingt, Ihre geschäftlichen Annahmen im Voraus zu durchdenken. Warum zwischen 1 und 99 Zeilen? Was passiert, wenn Sie 0 Zeilen erhalten (keine Probleme)? Was passiert, wenn Sie 100+ Zeilen erhalten (vielleicht ein Problem mit der Datenqualität)? Wenn Sie feststellen, dass Sie in verschiedenen Umgebungen unterschiedliche Einschränkungen anwenden müssen, machen Sie dies einfach vom Ziel abhängig min_value: "{{ 99 if target.name != 'prod' else 100000 }}". Wenn Sie den Test zuerst schreiben, sind Sie gezwungen, diese Entscheidungen explizit zu treffen, bevor Sie mit der Codierung beginnen.

Natürlich müssen Sie nicht unbedingt vorhandene Tests verwenden. Die Pakete dbt_utils und dbt_expectations enthalten zahlreiche Hilfsfunktionen, die Ihnen den Einstieg erleichtern. Sie könnten zum Beispiel einen expect_sum_between Test erstellen.

models:
  - name: daily_problems_summary
    tests:
      - expect_sum_between:
          sum_column: users
          min_value: 1
          max_value: 99
          group_by: "problems"
          row_condition: "batch != 1"

Dieser benutzerdefinierte Test kann das vorhandene dbt_expectations.expression_between Makro mit etwas mehr Zucker verwenden.

{% test expect_sum_between(model, sum_column, min_value=None, max_value=None, group_by_columns=None, row_condition=None, include_boundaries=true) %}

    {{ dbt_expectations.expression_between(model, 'sum(' ~ sum_column ~ ')', min_value, max_value, group_by_columns, row_condition, strictly=include_boundaries) }}

{% endtest %}

Die wichtigste Erkenntnis dabei ist, dass Sie nicht auf die integrierten Tests von dbt beschränkt sind. Sie können benutzerdefinierte Tests erstellen, die Ihre Geschäftslogik kapseln und sie in allen Modellen wiederverwenden. Das ist der Punkt, an dem TDD wirklich glänzt - Sie definieren Ihr Testframework auf der Grundlage Ihrer spezifischen Anforderungen und erstellen dann Modelle, die diese Tests erfüllen.

Bewährte Praktiken & Tipps

Nachdem Sie nun die Theorie verstanden und einige Beispiele gesehen haben, lassen Sie uns über die praktische Seite der Implementierung von TDD in Ihrem dbt-Workflow sprechen. Wann sollten Sie Ihre Tests durchführen und wie vermeiden Sie die üblichen Fallstricke, die Ihrer Teststrategie mehr Ärger einbringen können, als sie wert ist?

Wann Sie Tests durchführen

Die kurze Antwort, wie ein guter Berater: Es kommt darauf an. Aber hier ist ein praktischer Ansatz, der Gründlichkeit und Pragmatismus in Einklang bringt.

Lokale Entwicklung: Führen Sie bei jeder Änderung Unit-Tests und Modellverträge durch. Diese sind schnell und erkennen Logikfehler sofort. Datentests können teuer sein. Führen Sie sie daher selektiv durch - vielleicht nur für die Modelle, an denen Sie aktiv arbeiten, oder für eine Teilmenge von Daten.

CI/CD-Pipeline: Führen Sie alle Tests aus, aber seien Sie dabei klug. Unit-Tests und Verträge sollten immer ausgeführt werden. Für Datentests sollten Sie Tags verwenden, um je nach Umgebung unterschiedliche Sätze auszuführen. Führen Sie vielleicht umfangreiche Aggregationstests nur in der Produktion durch oder verwenden Sie unterschiedliche Schwellenwerte für verschiedene Umgebungen.

Produktion: Hier wollen Sie eine ganze Reihe von Datentests durchführen, aber das Timing ist wichtig. Führen Sie keine Unit-Tests in der Produktion durch (sie werden nicht benötigt und verschwenden nur Rechenzeit). Nicht jeder Test muss jedes Mal mit allen Daten durchgeführt werden. Überlegen Sie sich gut, wann Sie Datentests durchführen (wöchentlich oder monatlich ist oft ausreichend) und verwenden Sie Tags, um Tests nach Bedarf zu aktivieren oder zu deaktivieren. Konzentrieren Sie sich auf Datentests und Verträge, die die tatsächliche Datenqualität so weit validieren, dass sie in der Produktion benötigt wird. Und denken Sie daran: Nur weil ein Test in der Entwicklung erfolgreich war, heißt das nicht, dass er auch in der Produktion erfolgreich sein wird - reale Daten überraschen Sie immer wieder.

Empfohlene Verwendung nach Umgebung

Umgebung	Einheitstests	Modell-Verträge	Daten-Tests
Lokale Entwicklung	✅ Immer laufen	✅ Läuft immer	⚠️ Selektiv (Teilmenge von (großen) Daten)
CI/CD-Pipeline	✅ Immer ausführen	✅ Immer ausführen	⚠️ Selektiv (Teilmenge von (großen) Daten)
Produktion	❌ Nicht erforderlich	✅ Kritisch für die Stabilität	✅ Kluges Timing (z.B. wöchentlich)

Organisieren von Tests und Testdaten

Wenn Ihr dbt-Projekt wächst, wächst auch Ihre Testsuite. Hier erfahren Sie, wie Sie sie überschaubar halten können:

Verwenden Sie Tags, um Tests nach Zweck zu organisieren: Erstellen Sie Tags wie critical, slow oder business_logic, um Teilmengen von Tests auszuführen, je nachdem, woran Sie gerade arbeiten. Zum Beispiel dbt test --select tag:business_logic,new_feature für alle business_logic-Tests nur im Ordner 'new_feature', damit Sie während der Entwicklung schnelles Feedback erhalten.

Nutzen Sie die dbt-Knotenselektoren: Verwenden Sie das --exclude-resource-type unit_test Flag, um Unit-Tests in der Produktion auszuschließen und @state:modified, um alle relevanten Tests und Modelle zu erfassen.

Fassen Sie verwandte Tests zusammen, aber nicht zu sehr: Halten Sie Tests, die das gleiche Geschäftskonzept überprüfen, nahe beieinander. Wenn Sie mehrere Tests für die Qualität von Kundendaten durchführen, sollten Sie diese in derselben YAML-Datei zusammenfassen oder konsistente Benennungsmuster verwenden. Gleichzeitig werden Sie nicht pro YAML-Datei abgerechnet. Scheuen Sie sich also nicht, Tests der Einfachheit halber aufzuteilen.

Erstellen Sie Testdaten für Unit-Tests: Verlassen Sie sich bei Unit-Tests nicht auf die Produktionsdaten. Erstellen Sie kleine, kontrollierte Datensätze, die die Randfälle repräsentieren, die Sie testen möchten. Dadurch werden Ihre Tests schneller, zuverlässiger und einfacher zu debuggen. Diese werden als "Fixtures" bezeichnet und können entweder direkt im Unit-Test in einer YAML-Datei oder als CSV- oder SQL-Datei im Fixtures-Ordner gespeichert werden.

Dokumentieren Sie Ihre Testannahmen: Wenn Sie einen Test schreiben, dokumentieren Sie, warum er existiert und welche Geschäftsregel er durchsetzt, vorzugsweise im Beschreibungsfeld. Sie (und Ihre Teamkollegen) werden es Ihnen danken, wenn sie in Zukunft verstehen müssen, warum ein Test fehlschlägt.

Fazit

Bei der testgesteuerten Entwicklung im dbt geht es nicht nur um das Schreiben von Tests, sondern auch darum, Ihre Denkweise von "erst bauen, dann testen" auf "erst den Erfolg definieren, dann bauen" zu ändern. Die Vorteile liegen auf der Hand: Sie erkennen Probleme frühzeitig, Sie sind gezwungen, Ihre Geschäftslogik im Voraus zu durchdenken, und Sie erhalten zuverlässigere, besser wartbare Datenmodelle.

Genau wie in der Softwareentwicklung ist TDD kein Patentrezept und muss nicht dogmatisch befolgt werden. Sie brauchen nicht für jedes Modell eine 100%ige Testabdeckung, und manchmal ist es sinnvoller, das Modell zuerst zu schreiben - vor allem bei Sondierungsarbeiten oder wenn Sie noch herausfinden müssen, wie die Daten aussehen sollen. Das Ziel ist nicht, ein TDD-Purist zu sein, sondern das Testen als ein Werkzeug zu verwenden, das Ihnen hilft, bessere Datenmodelle zu erstellen. Einige Modelle benötigen umfangreiche Tests, andere wiederum kommen mit einigen wenigen Schlüsselaussagen aus. Das Wichtigste ist, dass Sie sich bewusst machen, was Sie testen und warum.

Der Schlüssel ist, klein anzufangen. Wählen Sie ein Modell aus, schreiben Sie einen einfachen Test, der definiert, wie "gut" aussieht, und bauen Sie dann das Modell so, dass es diesen Test besteht. Sobald Sie sehen, wie es funktioniert, können Sie es ausbauen. Nutzen Sie die Werkzeuge, die dbt zur Verfügung stellt - Unit-Tests, Modellverträge, benutzerdefinierte Tests - aber lassen Sie das Perfekte nicht der Feind des Guten sein. Ein paar gut platzierte Tests, die echte Probleme abfangen, sind mehr wert als eine umfassende Testsuite, die nie ausgeführt wird.

Denken Sie daran, dass es nicht darum geht, alles zu testen, sondern die Dinge, die wichtig sind. Konzentrieren Sie sich auf die Geschäftslogik, die im Falle eines Fehlers echte Probleme verursachen würde, und lassen Sie sich von Ihren Tests bei der Entwicklung leiten. Ihr zukünftiges Ich (und Ihre Stakeholder) werden es Ihnen danken.

dbt Test Strategie Übersicht

Strategie testen	Wann Sie es verwenden sollten	Am besten für	Umgebung	Beispiel Anwendungsfall
Einzelspalte Zeile für Zeile	Immer für kritische Spalten	Grundlegende Datenüberprüfung	Alle Umgebungen	Sicherstellen, dass Benutzer-IDs eindeutig und nicht null sind
Mehrspaltige Zeile-für-Zeile	Wenn sich Geschäftsregeln über mehrere Spalten erstrecken	Komplexe Validierungslogik	Alle Umgebungen	Überprüfung von eindeutigen Kombinationen von Produkt + Datum
Vollständiges Modell / Aggregationstests	Wenn Sie Annahmen über Datensätze hinweg validieren müssen	Validierung der Geschäftslogik	Entwicklung + Produktion	Sicherstellen, dass die Zeilenzahlen innerhalb der erwarteten Bereiche liegen
Model Unit Tests	Während der Entwicklung und beim Aufbau komplexer Geschäftslogik	Testen der Transformationslogik	Lokale Entwicklung + CI/CD	Testen von Datumsberechnungen und Geschäftsregeln
Makro-Einheitstests	Wenn Makros über mehrere Modelle hinweg verwendet werden	Sicherstellung der Konsistenz wiederverwendbarer Logik	Lokale Entwicklung + CI/CD	Testen von benutzerdefinierten Datumsfunktionen oder Berechnungen
Modell-Verträge	Wenn die Modellstruktur entscheidend ist und nicht geändert werden sollte	Erzwingen der Datenstruktur auf Datenbankebene	Alle Umgebungen (insbesondere Produktion)	Sicherstellen, dass nachgelagerte Abhängigkeiten nicht unterbrochen werden

__

Bild von Karolina Grabowska auf Pexels