debezium/dbz

Implement automated testing framework for debezium-examples

Open

#1 810 ouverte le 13 avr. 2026

Voir sur GitHub
 (16 commentaires) (0 réactions) (1 assigné)HTML (6 forks)auto 404
component/examplesgood first issuetype/task

Métriques du dépôt

Stars
 (3 stars)
Métriques de merge PR
 (Métriques PR en attente)

Description

Current Behaviour

Most examples in the repository lack automated tests, making it difficult to:

  • Verify examples work correctly after Debezium version upgrades
  • Catch breaking changes before they reach users
  • Ensure examples continue to work as Docker images and dependencies evolve
  • Maintain confidence in example code quality

Currently, only the postgres-failover-slots example has automated testing via GitHub Actions.

Expected Behaviour

Implement a test framework similar to the postgres-failover-slots example for all applicable examples.

Reference Implementation:

The postgres-failover-slots example demonstrates a working approach:

  • Test script: scripts/run-example-test.py - Python-based test runner
  • Test manifest: postgres-failover-slots/test.yaml - Declarative YAML DSL for test steps
  • GitHub Actions: .github/workflows/postgres-failover-slots-workflow.yml - CI integration

The test framework supports:

  • Docker Compose service orchestration
  • HTTP endpoint polling (for service readiness)
  • Database operations via docker compose exec
  • Kafka message consumption and verification
  • Flexible wait conditions and timeouts

Related

  • debezium/dbz#1165 PR discussion

Guide contributeur

Direction de recherche
Étudiez le cadre de test de référence dans l'exemple 'postgres failover slots', comprenez le lanceur de test Python, le manifeste YAML et le workflow GitHub Actions. Ensuite, appliquez le même modèle à un autre exemple qui manque actuellement de tests automatisés, en choisissant un exemple simple comme 'postgres' ou 'mysql'.
Stack technique
pythondockerpostgresqlkafka
Domaine
testingdevops
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
3-5 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GitDockerPython
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65