Suite à la migration et au design de la nouvelle API de reporting, une partie essentielle, le Query Composer, devait subir une refactorisation afin d’être mieux adaptée aux nouvelles fonctionnalités demandées par le produit.
Pour s’assurer que cette refonte n’entraîne pas de régressions dans les requêtes générées, un nouvel automate de test devait être mis en place.
L’objectif était de comparer un rapport demandé pour une période T à un moment M, d’en faire une référence dans le test, puis, les jours suivants, de demander un nouveau rapport avec les mêmes paramètres pour la même période T, mais à un moment M ultérieur (après une livraison, par exemple).
Avantages et inconvénients :
En raison de l’arrondi non déterministe sur les nombres à virgule flottante provenant de BigQuery, il était impossible de comparer exactement deux rapports demandés à des moments différents. Il a donc fallu introduire un système de parsing ligne par ligne acceptant un seuil de tolérance défini à trois chiffres après la virgule.
En plus de la comparaison des rapports et de la requête SQL générée par le Query Composer, dont le rapport découlait, il était nécessaire de vérifier que la requête ne scannait ni ne facturait plus d’octets, en s’appuyant sur des données issues d’une requête directe dans BigQuery.
Au final, ce sont 34 rapports et plus de 400 champs qui ont constitué ces tests de non-régression sur une API asynchrone hébergée sur GCP.