Principes de base des tests

Ce document fournit une présentation des concepts de base des tests, y compris :

Types de tests

Ce guide couvre trois types de tests courants que vous pouvez effectuer pour vérifier que votre code fonctionne correctement :

  • Tests unitaires
  • Tests d'intégration
  • Tests système

En général, les tests plus complets prennent plus de temps. Ce document présente ces types de tests en détail et explique comment trouver un équilibre entre rapidité et exhaustivité.

Tests unitaires

Les tests unitaires sont des tests restreints à des petites parties de votre code. Ils permettent de vérifier rapidement les hypothèses formulées au cours du processus de développement, telles que la gestion des cas marginaux et la validation des entrées.

Par nature, les tests unitaires ne testent pas l'intégration avec des dépendances externes, telles que Cloud Functions ou d'autres composants Google Cloud. Vous pouvez utiliser votre framework de simulation pour créer des versions simulées de dépendances externes.

Pour les fonctions HTTP, les tests doivent simuler le framework HTTP d'encapsulation. Combinez des frameworks de test et de simulation et comparez les résultats de votre fonction aux valeurs attendues pour vérifier le comportement de votre fonction.

Tests d'intégration

Les tests d'intégration valident l'interaction entre les différentes parties de votre code et prennent généralement un certain temps. Par exemple, dans Cloud Functions, les tests d'intégration peuvent être utilisés pour tester l'utilisation par une fonction d'autres services Google Cloud tels que Cloud Datastore ou Cloud Vision.

La principale différence entre les tests unitaires et les tests d'intégration de Cloud Functions réside dans le fait que les tests d'intégration impliquent moins de simulation que les tests unitaires. Les tests d'intégration doivent déclencher des événements Cloud réels, tels que des requêtes HTTP, des messages Pub/Sub ou des modifications d'objets Storage, et y répondre.

Vous pouvez exécuter des tests d'intégration au niveau local à l'aide d'un shim.

Certaines opérations asynchrones peuvent nécessiter des interrogations périodiques. Nous vous recommandons d'utiliser la stratégie d'interrogation par intervalle exponentiel entre les tentatives tronqué, car elle minimise efficacement la latence de l'opération sous-jacente, ainsi que la fréquence d'interrogation requise. L'intervalle exponentiel entre les tentatives tronqué est une stratégie standard de traitement des erreurs pour les applications réseau, où un client relance régulièrement une requête ayant échoué en observant des délais croissants entre les tentatives.

Tests système

Les tests système sont des tests plus complexes qui valident le comportement de votre fonction Cloud sur plusieurs composants Google Cloud dans un environnement de test isolé.

Déployez votre fonction Cloud dans un environnement de test et testez ses fonctionnalités en déclenchant les événements appropriés. Consultez les journaux ou vérifiez le comportement de la fonction pour la valider.

Bonnes pratiques pour les environnements de test

Tout d'abord, assurez-vous d'isoler vos environnements de développement, de test et de production. Afin de garantir des builds hermétiques, nous vous recommandons de provisionner de manière automatisée les ressources de test avec leurs propres projets GCP et/ou noms de ressources.

Ensuite, nous vous recommandons d'attribuer des noms uniques globaux aux ressources utilisées par les tests système afin d'empêcher que les tests réalisés simultanément interfèrent les uns avec les autres. Pour ce faire, vous pouvez créer et supprimer de manière automatisée les ressources requises avant et après chaque exécution du test.

Enfin, nous vous recommandons de séparer les valeurs de configuration de votre codebase. Les valeurs non secrètes peuvent être stockées en tant que variables d'environnement, tandis que les valeurs secrètes (telles que les mots de passe de base de données et les clés API) doivent être stockées à l'aide de Secret Manager