Vers des tests frontaux efficaces

J'interviewe depuis un bon moment. Ce qui ressort de ce processus douloureux, c'est que l'entretien est voué à l'échec si la question des tests est soulevée. En effet, mes expériences ont porté principalement sur le développement front-end et les deux entreprises dans lesquelles j'ai séjourné étaient très médiocres en matière de tests front-end.

--- Passer si vous souhaitez passer directement à la discussion ---

Mon manque était, dans un certain sens, un sous-produit de la culture industrielle. Les tests frontaux ont toujours existé, mais il y a dix ans, la structure de l'entreprise séparait les préoccupations liées aux tests du processus de développement. Nous avions donc une équipe d'assurance qualité dédiée qui écrivait des tests E2E/automatisés pour nous, les développeurs. Les tests ne figuraient donc même pas dans la description de poste. De plus, la triste vérité des petites startups est que la livraison est toujours avant tout, donc comme les tests entravent la productivité, nous, les développeurs, n'avons pas testé. Nous n'avions même pas de bibliothèque de tests (Jasmine/Mocha/PhantomJS...) installée dans le dépôt.

J'ai obtenu mon deuxième emploi dans une entreprise beaucoup plus grande (l'équipe de la plateforme grand public comptait environ 150 développeurs ?). Cependant, il n’y a pas eu de tests trop concrets. Chaque équipe (équipes divisées par fonctionnalités telles que le paiement, la fidélité, l'inscription...) comptait à nouveau un ou plusieurs membres dédiés au contrôle qualité qui passeraient ces tests E2E. Une fois que cette culture s’est installée et que l’assurance qualité a été supprimée du budget, personne ne s’en est chargé car il n’y avait personne de qui apprendre. J'ai essayé de faire quelques tests E2E pour notre équipe, mais le code laissé n'était même pas fonctionnel et plein de bugs évidents (beaucoup de WTF). Combinés à des délais serrés ENCORE, les tests ont pris du retard. La seule fois où les gens parlaient de tests, c'était pour les fonctions utilitaires et les hooks de réaction personnalisés.

--- la discussion commence ---

Étant en proie à la culture du non-test, je dois au moins trouver quelque chose que je puisse dire lors des entretiens sur les tests de manière abstraite. Je vais sauter les conneries habituelles de ne pas tester les styles ou la mise en œuvre, etc.

N'hésitez pas à contribuer à la discussion. Cela concerne au moins 300 de mes anciens collègues !

1.) tester les états globaux :
D'après mes expériences, l'une des fonctionnalités les plus délicates est le type de comportement "si cela se produit, nous le ferons automatiquement pour vous". Par exemple, une application que j'avais était un tableau de bord de visualisation graphique fortement configurable. Un changement de configuration peut également entraîner la modification d'autres configurations, en fonction des données renvoyées ou non. Certains effets secondaires de configuration ne sont pas simples. Vous souhaiterez donc tester les modifications automatiques de la configuration et savoir si l'état est persistant/inchangé/cohérent dans tous les domaines. Donc, si vous effectuez des tests autour de ce type de comportement, en accord avec le PM, les managers, la conception et l'équipe d'assurance qualité, c'est extrêmement précieux.

2.) ne passez pas beaucoup de temps à tester l'intégrité des entrées de l'interface utilisateur :
Je vois pas mal de tutoriels parlant de tester les entrées, comme lorsque je tape "Taylor Swift" dans la barre de recherche et que j'appuie sur Entrée, notre fonction de recherche obtiendra Taylor Swift comme entrée.

C'est carrément inutile. Si votre liaison de données est rompue, il sera très évident que vous auriez dû la détecter vous-même pendant le développement ou qu'elle ne sera pas automatiquement testable car quelque chose entravait la fonctionnalité, comme un div invisible au-dessus de la barre de recherche afin que les utilisateurs ne puissent pas taper dans la recherche.

Si vous êtes payé par lignes de code, allez-y :)

3.) tester les entrées comme effet secondaire des entrées, bien qu'il soit souhaitable :
contrairement au numéro 2, vous souhaiterez tester des appels fonctionnels qui sont complètement des effets secondaires de l'interaction de l'utilisateur. Par exemple, lorsque l'utilisateur clique sur un bouton, une requête doit être appelée pour enregistrer cette action utilisateur pour l'analyse des données. Ce type d'effet secondaire, complètement distinct de la fonctionnalité principale, doit être automatiquement testé afin que nous ne soyons pas pris au dépourvu par des changements involontaires. Les effets secondaires non essentiels peuvent être essentiels pour d'autres équipes, j'étais dans l'une de ces autres équipes :D

Alors, comment concevez-vous ces exigences en matière de tests ?
décomposons l'architecture frontend : MVC (vous pouvez dire que vous êtes MVVM ou autre, cela n'a pas vraiment d'importance).

V - view (html/jsx) : Ceci est idéal pour les tests de navigateur E2E/sans en-tête et constitue une norme de l'industrie.

C - contrôleur (logique métier) : passez du temps à vous assurer que les fonctions sont correctes. Par exemple, si vous avez/abstrait des fonctions pures, le processus d'entrée-sortie attendu est-il toujours intact ? Un peu standard de l'industrie, mais les gens ne prennent généralement pas la peine de transformer des fonctions avec état en fonctions pures et en tests.

M - modèle (appels/états API) : c'est ce sur quoi je veux me concentrer le plus. vos états (sans rendu) doivent être globaux et singleton par concept. Ce n’est pas une idée nouvelle, puisque Redux l’est fondamentalement. Cependant, il n'est pas nécessaire qu'il s'agisse de Flux pour nos besoins de tests. Vous pouvez avoir des atomes Jotai mais vous pouvez coder un wrapper afin de pouvoir exposer vos fonctions de définition centralisées à des fins de test.

la même chose devrait être faite sur vos appels API/bibliothèques tierces. Il doit être global et unique afin que vous puissiez tester en toute confiance "quand je fais cela, un appel d'API principal/non principal est effectué dans l'application". Cela se fait régulièrement dans, mon expérience limitée, les applications backend. Cela devrait également être fait dans les applications frontales.

Comment ça sonne ? Je suis sûr que quelqu'un le fait déjà, quelle est votre expérience ? que peut-on améliorer ? J'aimerais entendre des gens dire que les tests frontaux vont au-delà du navigateur E2E/sans tête et des tests unitaires simples.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!