Ce qu'il faut tester, et non ce qu'est le test, est une question importante pour toutes les équipes. Les tests sont un moyen d'atteindre une fin, et il peut être difficile de déterminer comment hiérarchiser les tests des différentes parties de votre codebase.
La meilleure façon de définir les priorités est basée sur votre codebase et les objectifs de votre équipe. Toutefois, n'oubliez pas que même si l'écriture de nombreux petits tests (en bas de la pyramide de tests, tels que les tests unitaires) présentant une grande couverture de code, nécessite peu de temps et de bande passante, ils ne réduisent pas nécessairement le risque global pour votre projet.
Vous pouvez choisir les éléments à tester en premier en pensant aux principaux cas d'utilisation de votre application, de votre site Web ou de votre bibliothèque. Pour cela, vous pouvez écrire des tests de composants sur des parties critiques de votre site, les principaux composants qui sous-tendent l'expérience utilisateur. Par exemple, les développeurs d'un site qui permet aux utilisateurs d'importer et de gérer des données de séries temporelles doivent imaginer et tester les différentes façons dont un utilisateur peut effectuer ces tâches.
Une autre approche de la hiérarchisation consiste à recueillir le plus d'informations possible. Si aucun membre de votre équipe n'aime travailler sur une partie de votre codebase "dangereuse", héritée ou mal écrite, il peut être utile de créer des tests pour améliorer la cohérence de son comportement avant de l'ignorer davantage ou de la refactoriser pour la corriger. Considérez cela comme l'échafaudage d'un bâtiment qui a déjà été condamné, mais qui héberge encore votre centre de données.
Dimensionnalité
Nous avons introduit le concept de pyramide de test, ou une autre forme de test, mais celles-ci ne présentent généralement qu'une seule dimension de test: une ligne qui va des tests unitaires simples, simples et complexes (tests unitaires par opposition aux tests d'intégration et tests de bout en bout).
Cependant, certains types de tests possibles ne sont pas un niveau de complexité, mais plutôt des objectifs ou des techniques de test. Par exemple, les tests de fumée constituent une catégorie différente de tests. Ils peuvent eux-mêmes être des tests unitaires, de bout en bout ou d'autres types de tests, mais ils sont destinés à garantir aux testeurs l'assurance globale que le projet testé est dans un état valide. Les tests visuels peuvent également être utiles pour un petit composant ou sur votre site dans son ensemble.
Votre codebase aura des exigences uniques. Par exemple, il peut être beaucoup plus important dans votre codebase de s'aligner sur une seule fonctionnalité, d'écrire différents types de tests pour s'assurer qu'il fonctionne correctement. Une nouvelle fonctionnalité devant être testée est rarement un seul composant, une seule fonction ou une seule approche, et son impact sur votre projet peut être largement diffusé et à différentes échelles.
Vos priorités en termes de tests peuvent également dépendre des besoins de votre entreprise. Les systèmes très techniques peuvent nécessiter des tests unitaires complexes pour confirmer le bon fonctionnement d'un algorithme unique, tandis que les outils hautement interactifs sont susceptibles de se concentrer sur les tests visuels ou de bout en bout pour confirmer que les entrées tactiles complexes génèrent la bonne réponse.
Votre approche des tests
Essayez de tester les cas d'utilisation de votre codebase, quelle que soit leur envergure. Imaginez comment l'utilisateur pourrait utiliser n'importe quelle partie de votre projet. Il peut s'agir d'un composant unique, d'une fonction de niveau inférieur ou d'un cas d'utilisation de haut niveau de bout en bout. (Cela peut également révéler des lacunes dans vos abstractions, quelle que soit l'échelle, si vous constatez que votre test ne peut pas interagir correctement avec le code testé.)
Il est important que chaque scénario de test ait un objectif clairement défini. Les tests "catch-all" volumineux peuvent être gênants, tout comme dans votre code qui n'est pas un test.
Remarque sur le développement piloté par les tests
Le développement piloté par les tests (TDD, Test-driven development) est une approche unique des tests, orthogonale du scaling ou des types, dans la mesure où il implique l'écriture de tests qui doivent au moins échouer dans un premier temps. Cela peut s'appliquer aux tests manuels et automatisés: vous décrivez les objectifs que vous souhaitez atteindre, découvrez ce qui manque dans votre solution ou votre code actuels, et utilisez le test qui échoue comme aide pour trouver une solution.
Bien sûr, il n'est pas utile de tester tous les scénarios possibles dans une application ou un composant hypothétique, avant même de commencer à la créer. Le TDD a sa place, et il peut être utile à mesure que votre codebase devient plus complexe.
Le TDD est également une bonne pratique pour corriger les bugs. Si vous pouvez codifier le cas de reproduction d'un bug, il peut être intégré à un test automatisé qui échouera initialement. Une fois le bug corrigé, le test réussit, ce qui vous permet de déterminer si le correctif a réussi sans confirmation manuelle.
Boîte de dialogue opaque ou transparente
Il s'agit de la façon dont vous testez une partie du système. S'il est opaque, vous ne pouvez pas voir l'intérieur, par exemple lorsque vous utilisez l'interface publique d'une classe, plutôt que d'inspecter ses éléments internes.
À moins que vous n'ayez une raison spécifique de ne pas le faire, il est préférable de commencer par des tests en boîte opaque afin de pouvoir concevoir des tests en fonction de la façon dont vos composants sont utilisés, sans vous laisser distraire par le fonctionnement de leurs composants internes. Si vous n'utilisez que l'interface "publique" d'un chemin de code (pas nécessairement publique pour vos utilisateurs, mais peut-être pour d'autres parties de votre code), vous êtes libre de refactoriser et d'améliorer ce code en sachant que votre test détectera toute modification.
Une façon de convertir votre code de boîte blanche pour le rendre plus opaque consiste à introduire des éléments configurables, tels que des abstractions pour les dépendances du code ou des rappels pour observer l'état, au lieu que cet état soit étroitement couplé à d'autres systèmes. Cela permet de mieux découpler votre code et de fournir des versions de test. Vous pouvez également simuler où votre code interagit avec d'autres systèmes.