Comment structurez-vous une base de code d'automatisation d'interface pour qu'elle ne devienne pas immaintenable ?

Séparez les couches. Les objets de page ou de composant encapsulent les sélecteurs et les interactions de bas niveau ; une couche de parcours les compose en actions métier comme se connecter ou finaliser une commande ; les tests ne contiennent que l'intention et les assertions. Gardez les sélecteurs à un seul endroit, préférez des identifiants de test dédiés aux chemins CSS fragiles, et gardez les assertions hors des objets de page pour que les échecs pointent la bonne couche.

Je traite le code de test comme du code de production, donc les mêmes règles s'appliquent : pas de duplication, des couches claires, des noms parlants. Tout en bas j'ai des objets de page ou de composant qui possèdent les sélecteurs et la mécanique d'interaction avec ce morceau d'interface. Au-dessus se trouve une couche de parcours pour les actions de niveau métier, du genre se connecter avec un utilisateur ayant ce rôle, ou ajouter un article et finaliser la commande, parce que ces séquences sont réutilisées en permanence et que vous ne voulez pas les voir copiées-collées dans quarante tests. Les tests se lisent alors comme l'exigence, essentiellement des appels de méthodes et des assertions. Je garde les assertions hors des objets de page, parce que quand un objet de page fait une assertion, un échec vous dit qu'une page est mécontente plutôt que quel comportement a cassé. Sur les sélecteurs, je pousse fort pour des attributs de test dédiés convenus avec les développeurs, parce que courir après des chemins CSS qui changent dès que quelqu'un restyle un composant est la raison principale de l'abandon de ces suites. Et je fais la préparation via l'API dès que possible : si un test porte sur la commande, créer le compte et le panier en HTTP est plus rapide et bien moins instable que de piloter douze écrans pour y arriver.