validation

Le Driver Validation Suite est un framework de tests réutilisable et extensible pour valider les pilotes ADBC (Arrow Database Connectivity), construit avec Python et pytest. Il teste diverses fonctionnalités ADBC et types de données en exécutant des requêtes SQL contre les pilotes cibles, et génère des tableaux de documentation listant les fonctionnalités supportées et non supportées. La suite peut gérer les particularités syntaxiques et comportementales propres à chaque base de données. Les cas de test sont organisés sous le répertoire queries/base, chaque test individuel comprenant tous les fichiers d'un même répertoire partageant un nom de base commun. Trois types de requêtes principaux sont supportés : 1. Requêtes SELECT : testent l'exécution d'une requête et la validation de son résultat, composées d'un fichier query.sql, du schéma attendu (query.schema.json), des données attendues en JSON Lines (query.json), plus des fichiers optionnels de setup SQL, de paramètres liés, de schéma lié et de requête liée. 2. Requêtes de schéma : testent la récupération du schéma du jeu de résultats sans exécution, nécessitant uniquement query.sql et le fichier de schéma attendu. 3. Requêtes d'ingestion : testent l'ingestion par lot de données Arrow suivie d'une requête sur la table chargée, nécessitant des fichiers de schéma et de données d'entrée, avec schéma et données attendues optionnels. Tous les cas de test peuvent inclure un fichier metadata query.toml pour contrôler le comportement et la sortie documentaire : le flag hide ignore le test pour un pilote donné, le flag skip marque le test comme non supporté avec une raison fournie, sort-keys définit les colonnes par lesquelles trier les jeux de résultats avant comparaison, et tags peut ajouter des réserves, marquer un support partiel ou spécifier le nom du type SQL pour la documentation. Les pilotes peuvent surcharger les cas de test de base avec des ajustements spécifiques au pilote en plaçant des fichiers au même chemin relatif dans leur répertoire quirks désigné, évitant ainsi de dupliquer des cas de test complets. En alternative aux définitions de test par fichier séparé, un seul fichier .txtcase peut être utilisé, avec des commentaires // part: indiquant quelle section correspond à quel type de fichier original. Les fichiers .txtcase ne peuvent pas être mélangés avec des fichiers séparés pour le même cas de test, car cela provoquera des erreurs de découverte des tests. Le projet indique que la documentation formelle est encore en cours de réalisation et recommande aux utilisateurs de consulter les implémentations existantes de pilotes ADBC pour apprendre comment intégrer la suite de validation.