Guide du débutant sur les tests: gestion des erreurs des cas de périphérie

Lors de la création de logiciels complexes, quelle que soit la langue, vous commencez à remarquer un modèle dans vos habitudes de test. Les mêmes problèmes d'aspect similaire se poseront sur différentes plates-formes ou projets. Que vous construisiez une autre démo de liste de tâches simple pour une présentation ou que vous conceviez un back-end complet pour une startup PaaS, les mêmes modèles génériques commencent à émerger.

Il y a six cas à tester qui permettront de mettre en lumière un nombre surprenant de problèmes. Celles-ci ne sont pas censées être complètes ou constituer une suite de tests complète. Il s'agit plutôt d'un sous-ensemble facile à retenir de paradigmes de test communs qui peuvent s'appliquer à n'importe quel langage, framework ou environnement.

Ces cas sont immédiatement utiles dans deux aspects des routines de codage quotidiennes: déboguer des problèmes spécifiques au fur et à mesure qu'ils surviennent, et dans la création de la suite de tests pour une base de code. Ils sont destinés à être des formes de test génériques et abstraites qui permettront de mettre en lumière certains des problèmes les plus courants auxquels les développeurs juniors sont confrontés.

Celles-ci ne seront utiles que de manière détournée en programmation fonctionnelle. La programmation fonctionnelle évite la plupart des types de bogues les plus simples décrits ci-dessous. Dans tous les cas, il est utile de garder à l'esprit ces types de cas de limites abstraits, car ils fournissent une barrière contre les mauvaises pratiques dans le code.

Les six tests sont les suivants:

  • Zéro
  • Un
  • Deux
  • Deux à max-1
  • max
  • max + 1

Même s'il s'agit de cas limites, leur valeur réside dans ce qu'ils représentent. Tout en vous assurant que vos tests couvrent toutes les fonctionnalités de votre programme, vous devez garder vos tests simples avec le moins de flair possible.

Zéro

Zéro est utilisé pour signifier toute forme d'entrée nulle, qu'elle soit indéfinie, nulle, un tableau vide ou simplement le nombre réel 0. La forme de bogue la plus courante et la plus simple fait référence à une valeur zéro, et elle doit toujours être testée. Testez simplement une fonction, un point de terminaison ou un téléchargement avec une entrée Zéro et vérifiez qu'il se comporte comme prévu.

Un

L'un, comme le zéro, est la forme la plus élémentaire du test unique générique. La fonction est testée avec la première entrée normale valide. Ceci est très utile pour les tests de régression. Dans les futures itérations du code, ce test indiquera rapidement si le programme (ou processus) fonctionne comme prévu.

Un test vous donne une base de référence pour le succès, qu'il s'agisse d'une authentification réussie sur un point de terminaison administrateur, d'un téléchargement de fichier valide ou d'une modification correcte du tableau.

Deux

Deux ne consiste pas simplement à tester l'indice de tableau 2, ou si votre algorithme fonctionne avec 2 entrées. Il englobe également ce qui se passe lorsque vous exécutez deux fois le même code.

Si quelqu'un devait faire une requête DELETE HTTP deux fois de suite à la même ressource, que se passe-t-il? Si la fonction de tri avec un comparateur personnalisé est appelée deux fois de suite, se comporte-t-elle comme prévu?

Deux est un nombre intéressant, car c'est la première fois qu'un code valide qui fonctionne lorsqu'il est appelé une fois peut montrer des effets secondaires lors d'exécutions répétées. Apportez un petit changement aux fonctions que nous avons testées ci-dessus.

Il s'agit de modifications d'état et de compréhension du comportement d'une fonction. Si tout ce que nous avons est le nom de la fonction, ce code se comporte exactement comme prévu. Vous avez une variable appelée 0, vous appelez la fonction setVarToOne, puis vous affirmez qu'elle est égale à un.

À première vue, cela s'est comporté exactement comme prévu. Cependant, le tester avec l'idée de Two à l'esprit mettrait en évidence des problèmes plus profonds avec le code. Vous le testeriez en l'appelant deux fois et en affirmant que dans les deux cas, mVar est égal à 1.

Deux à max-1

Deux à max-1 est le contrôle de cohérence. C'est très similaire au test One, mais il y a une différence subtile. Cela devrait être un cas d'utilisation moyen - pas le plus simple ou le plus direct, ou le plus facile à lire. Juste un cas d'utilisation moyen qui n'est peut-être pas particulièrement simple, mais qui est assez courant .

Max

Max est assez simple: il teste simplement les limites de votre application, en particulier autour des constantes max définies.

Si vous avez une implémentation de liste chaînée simple, vous pouvez imaginer que vous avez un nombre apparemment infini d'insertions autorisées. En réalité, il existe une limite supérieure - que ce soit INT_MAX, le nombre de descripteurs de fichiers que votre système d'exploitation peut avoir ouverts, ou simplement la quantité de mémoire ou d'espace disque allouée à votre programme.

Dans certaines circonstances, Max peut sembler un test impossible car il n'y a pas de maximum connu pour tout ce que vous testez. Son objectif dans ces cas, cependant, est d'une autre nature: tester votre candidature.

Par exemple, il est possible qu'une certaine partie de données soumises par l'utilisateur soit réduite et transmise à des fonctions jusqu'à ce qu'elle atteigne une boucle que vous avez définie. Si ces données sont, par exemple, INT_MAX, cela peut prendre un temps non négligeable pour que votre code se termine. Pire encore, cela pourrait jeter votre code dans un état non interrompu. Il peut s'agir de problèmes subtils qui ne surviennent qu'une fois que votre code entre en production, il est donc important de les détecter pendant la phase de test.

Max + 1

Max + 1 est un test principalement utilisé pour vérifier les normes ou règles mises en place par le programmeur. Cela implique de tester quoi que ce soit à sa limite théorique + epsilon.

Cela peut se manifester par un problème de tableau hors limites, une erreur par une erreur, une erreur de dépassement d'entier ou tout autre type de problème qui se produit lorsque vous atteignez les limites de votre fonction ou programme.

Si vous avez une taille de téléchargement de fichier maximale de 2 Mo, essayez de télécharger un fichier d'une taille de 2 Mo + 1b. Si vous avez une limite sur le nombre d'entrées dans un catalogue utilisateur, assurez-vous que la vérification se produit à la fois côté client etdu côté serveur.

Conclusion

Comme mentionné ci-dessus, ce n'est pas une image complète de ce que devraient être vos routines de débogage ou de test. Cela fournit simplement une base de référence solide et générique qui devrait transcender toute suite ou cadre de test spécifique.

Les tests sont généralement considérés comme des cas limites ou marginaux, mais ils peuvent élever leur tête laide dans des endroits qui ne sont pas immédiatement évidents.