Réponse.

Historique de la question :

À l'origine, les tests automatisés étaient souvent écrits "à la volée", sans séparations architecturales : la logique de vérification et les mécanismes d'exécution étaient mélangés. Avec la croissance des projets, il est devenu évident que le mélange du framework et de la logique de test crée une base de code fragile et difficile à maintenir. Des recommandations architecturales pour la séparation des responsabilités ont vu le jour.

Problème :

Si les tests dépendent des implémentations internes du framework ou incluent des logiques d'interaction avec l'environnement, tout changement oblige à réécrire de nombreux tests. Les cas de test sont complexes, le code est dupliqué, la migration vers un nouveau framework ou une nouvelle plateforme est compliquée.

Solution :

Séparer strictement :

Framework (infrastructure de base) : mécanique générale de lancement des tests, journalisation, gestion des erreurs, rapports, base pour les classes d'assistance (par exemple, pilotes, adaptateurs et utilitaires).
Logique de test (cas de test) : scénarios spécifiques qui expriment l'objectif significatif du test, utilisant uniquement les API publiques du framework.

Caractéristiques clés :

Facilité de maintenance grâce à l'isolation des changements de la plateforme
Possibilité de réutiliser la logique de test
Réduction de la redondance et de la duplication du code

Questions pièges.

Peut-on écrire des étapes de test directement dans les tests, si elles sont très peu nombreuses ?

Il vaut mieux éviter. Même les tests courts peuvent croître, et l'absence de couches conduira rapidement au chaos.

Les scénarios de test doivent-ils connaître la mécanique de lancement (par exemple, quand initialiser le pilote) ?

Non. Tous les détails de l'infrastructure doivent être cachés dans la couche du framework.

Est-il normal de coder en dur les paramètres de test à l'intérieur des cas (par exemple, url, identifiants) ?

Non. Les paramètres de test doivent être configurés via les paramètres du framework et de l'environnement.

Erreurs typiques et anti-patterns

Placement de la vérification d'état à l'intérieur des méthodes du framework, plutôt que dans les tests
Utilisation de méthodes privées du framework dans les tests
Duplication des fonctions d'assistance dans les tests
Hardcodage des paramètres

Exemple de la vie

Cas négatif

Dans le projet, les tests appellent directement les méthodes du pilote Selenium, la connexion à WebDriver est répétée dans chaque test. Chaque test analyse le config par lui-même.

Avantages :

Il est possible de commencer rapidement à écrire des tests automatiques sans architecture

Inconvénients :

Un changement de pilote ou de paramètres de lancement entraîne de nombreuses modifications
Code dupliqué dans tous les tests
Difficile de mettre à l'échelle et de maintenir le projet

Cas positif

Les tests utilisent des abstractions de base du framework : initialisation et teardown générales, passage des paramètres à travers un configurateur, la logique de test s'exprime à travers des méthodes de haut niveau.