Pourquoi Threat Stack automatise les tests de microservices à l'aide de conteneurs

Les microservices, même lorsqu'ils sont conçus correctement, peuvent être difficiles à tester. Mais lorsque l’architecture du système évolue au point où des dizaines ou des centaines de services connectés constituent une plate-forme logicielle dans une infrastructure en constante évolution, alors tester le produit dont vous et votre équipe êtes responsables devient une tâche monumentale et complexe. L'écriture de tests automatisés pour ces environnements est difficile, vous devez donc vous assurer de tirer le meilleur parti des tests que vous écrivez.

Chez Threat Stack, nous écrivons des tests d'intégration système, une forme de test fonctionnel en boîte grise, et nous choisissons Docker pour exécuter l'environnement de test conteneurisé.

Quel est le problème avec les autres types de tests ?

Certaines organisations s’appuient encore sur le modèle de test traditionnel, dans lequel les tests en boîte blanche et en boîte noire sont considérés comme une stratégie de test complémentaire suffisante. Bien qu’ils jouent toujours un rôle important dans la qualification des logiciels, ils ne suffisent plus à vous donner le retour d’information dont vous avez besoin pour publier des logiciels en toute confiance.

Dans ce type d'environnement, les tests d'acceptation utilisateur en boîte noire sont trop largement ciblés et s'appuyer sur eux peut avoir de graves conséquences sur les stratégies de mise sur le marché :

• Il n’offre pas une couverture adéquate, car il y a trop de scénarios possibles à tester dans le temps alloué à l’exécution des tests.
• Il s’exécute pendant de longues périodes et peut souvent expirer en raison de facteurs indépendants de la volonté de votre application.
• Il doit être exécuté après le déploiement du service, plutôt qu'au moment de la création, ce qui signifie que les commentaires sont encore plus séparés du développement du produit. Dans la philosophie du glissement vers la gauche qui domine l'ingénierie des tests, s'appuyer sur ces tests rend votre organisation moins compétitive.
• Parce qu’il s’agit de tests de boîte noire, déterminer la cause des échecs peut être une tâche incroyablement difficile.
• Ils ne sont pas faciles à écrire ou à maintenir par les développeurs.

D'un autre côté, les tests unitaires en boîte blanche sont trop étroitement ciblés et sont souvent utilisés de manière incorrecte pour qualifier les fonctionnalités du système logiciel :

• Il ne prend pas en compte le comportement réel des services interagissant avec des composants ou d’autres services.
• Il peut tester des scénarios dénués de sens qui ne sont pas suffisamment utiles pour être maintenus.
• Cela peut devenir fastidieux pour les développeurs qui doivent continuellement mettre à jour de grandes collections de tests pour de petites modifications du code.
• Il n’est pas facile à écrire ou à maintenir par les ingénieurs de test.

Pourquoi se concentrer sur les tests d’intégration système ?

Les ingénieurs de test de Threat Stack s'appuient de plus en plus sur les tests d'intégration système pour tester tous ces services d'une manière qui maximise la couverture des tests tout en fournissant simultanément la vitesse et la spécificité dont nous avons besoin pour garantir que l'application se comportera correctement dans de nombreuses conditions opérationnelles.

Un test d'intégration est un test de boîte grise qui se concentre sur le comportement du logiciel ou du système testé lors de l'interfaçage avec des composants externes. Par exemple:

• Un magasin de données, par exemple PostgreSQL, Cassandra, ElasticSearch
• Un courtier de messages, par exemple Kafka
• Un serveur HTTP

En d’autres termes, un logiciel avec lequel vous pouvez interagir pour valider un comportement. Chez Threat Stack, nous exécutons principalement des tests fonctionnels qui reproduisent des situations réelles, mais les comportements testés s'arrêteront aux limites de l'environnement conteneurisé, évitant les interactions externes indésirables.

Et comme ces tests sont étroitement liés au microservice, vous avez l’avantage d’examiner et d’intégrer le code du service testé dans les tests automatisés pour identifier systématiquement les zones du code à exercer. De plus, ces tests peuvent être écrits comme des tests d'acceptation utilisateur afin que les non-développeurs, tels que les chefs de produit et les ingénieurs QA, puissent plus facilement comprendre le comportement testé.

Autrement dit:

Étant donné un ensemble de conditions

Lorsque le service reçoit cette entrée (OU cette condition affecte le service)

Ensuite, le service se comporte de la manière attendue et produit les effets secondaires attendus

Non seulement ces tests fonctionnels sont faciles à comprendre et à écrire, mais ils sont également étroitement couplés au code du microservice, de sorte qu’ils peuvent être facilement exécutés et mis à jour par les développeurs tout au long du processus de développement ou par la suite par des ingénieurs de test dédiés.

Pourquoi utiliser des conteneurs ?

Les conteneurs sont extrêmement utiles pour les systèmes de test car ils vous permettent de reproduire rapidement votre environnement de test avec un minimum de ressources pendant la durée des tests, puis de les nettoyer facilement une fois l'exécution des tests terminée. Contrairement à de nombreuses automatisations de tests de boîte noire, vous n’avez pas besoin d’un environnement de test coûteux et toujours actif pour effectuer vos tests d’intégration. Lorsque vous exécutez les tests, le comportement du microservice peut être reproduit dans l’environnement de test. 

Une fois que vous avez défini un environnement conteneurisé qui reflète l’environnement du microservice en production, votre infrastructure de test devient les clients externes ou les services fictifs qui s’interfacent avec les composants ou le microservice testés. Cela garantit que le code de test pilote tous les aspects des tests, ce qui vous permet de contrôler de nombreux autres aspects des tests.

Au début, Docker est une bonne plateforme pour créer rapidement un environnement conteneurisé. Grâce à Docker Compose , vous pouvez facilement définir et exécuter les sections de votre application testées, soit localement, soit en CI en utilisant le même code. D'autres outils et services d'infrastructure de conteneurs, tels que Kubernetes , AWS EKS ou AWS Fargate , peuvent également être utilisés pour déployer votre environnement de test si votre organisation prend en charge leur utilisation.

Conclusion

En fin de compte, la décision de concentrer les efforts de test sur les tests d’intégration plutôt que sur d’autres types d’automatisation vous offre deux grands avantages :

• Vos tests de microservices sont décalés vers la gauche afin qu'ils s'exécutent avant le déploiement, ce qui vous donne un retour plus rapide pour le développement itératif.
• Vous exécutez toujours des tests sur des services et des composants réels, ce qui signifie que vous réduisez les écarts de couverture des tests tout en exécutant toujours des tests fonctionnels.