Qu'est-ce que le test unitaire signifie pour vous?

Question

G'day,

Je travaille avec un groupe de développeurs offshore qui utilisent le terme de tests unitaires de manière assez vague.

Leur document d'assurance qualité parle de la rédaction de tests unitaires puis de la réalisation des tests unitaires du système.

Cela ne correspond pas à mon interprétation de ce que sont les tests unitaires.

Je suis habitué à ce que les tests unitaires soient des tests ou une suite de tests utilisés pour exercer une classe unique, généralement en tant que boîte noire. La classe sous test peut nécessiter l'inclusion d'autres classes dans l'implémentation, mais il s'agit généralement d'une classe unique qui est exercée par le ou les tests unitaires.

Vous avez ensuite des tests de fonctionnement du système, des tests d'intégration, des tests d'acceptation, etc.

Je veux savoir si c'est un peu pédant de ma part? Ou est-ce ce que vous pensez en parlant de tests unitaires et de tests unitaires?

Édition: Rob Wells. Je dois préciser que le fait d’aborder de tels tests du point de vue de la boîte noire n’est qu’un aspect. Lorsque vous utilisez des objets fantaisie pour vérifier les comportements internes, vous effectuez un test selon une perspective de boîte blanche, car vous savez ce que vous voulez qu'il se passe dans la boîte.

Answer 1

J'essaie d'implémenter des tests unitaires pour ne tester qu'une seule méthode. et je fais un effort pour créer " mock " classes pour les classes dépendantes et méthodes utilisées par la méthode que je teste ... ... de sorte que l'exercice du code dans cette méthode n'appelle pas le code dans d'autres méthodes, le test unitaire n'est pas censé être "Test", (Il existe d’autres tests unitaires pour ces méthodes). Ainsi, un échec du test unitaire indique de manière fiable un échec de la méthode testée par l’unité ...

Les classes simulées sont conçues pour "simuler". l'interface et le comportement des classes dépendantes afin que la méthode que je teste puisse les appeler et qu'elles se comportent de manière standard et bien définie en fonction des exigences du système. Pour que cette approche fonctionne, les appels à ces classes dépendantes et à leurs méthodes doivent être passés sur une interface bien définie, de sorte que le "testeur" processus peut " injecter " la version simulée de la classe dépendante dans la classe testée au lieu de la version de production réelle .... Cela ressemble un peu à un modèle de conception commun appelé "injection de dépendance" ou "inversion du contrôle". (CIO)

Il existe plusieurs outils tiers sur le marché pour vous aider à mettre en œuvre ce type de modèle. Un de ceux dont j'ai entendu parler est appelé "Rhino-Mock". ou quelque chose comme ça ...

Édition: Rob Wells. @Charles. Merci pour cela. J'avais oublié d'utiliser des objets fictifs pour les remplacer complètement par d'autres classes, à l'exception de celle testée.

Deux autres choses dont je me suis souvenu après avoir mentionné des objets fictifs sont les suivantes:

• ils peuvent être utilisés pour simuler les erreurs renvoyées par les classes incluses.
• ils peuvent être utilisés pour générer des exceptions spécifiques afin de vérifier la gestion des exceptions dans la classe sous test.
• ils peuvent être utilisés pour simuler des éléments pour lesquels les coûts d’installation sont élevés, par exemple. une grande base de données SQL.
• ils peuvent être utilisés pour vérifier le contenu d'une requête entrante.

Pour plus d'informations, consultez l'article de Martin Fowler intitulé " Mocks Arnt Stubs " et l'article de The Pragmatic Programmers & Objets factices "

Answer 2

Les développeurs utilisent généralement les tests unitaires pour tester des sections de code isolées. Ils couvrent les cas frontières, les cas d'erreur et les cas normaux. Ils sont destinés à démontrer la justesse d'un segment de code limité. Si tous vos tests unitaires réussissent, vous avez alors démontré que vos segments de code isolés font ce qu’ils sont censés faire.

Lorsque vous effectuez des tests d'intégration, vous examinez des cas de bout en bout pour voir si tous les segments ayant réussi les tests unitaires fonctionnent ensemble. Les tests fonctionnels vérifient si le code répond aux exigences spécifiées. Les utilisateurs finaux effectuent des tests d'acceptation pour vérifier s'ils approuvent le produit final.

Answer 3

Il n’existe aucune raison pour que les tests unitaires ne couvrent pas plusieurs classes, ni même des sous-modules, tant qu’ils ne traitent qu’une seule opération commerciale cohérente. Pensez à "CalculateWage", une méthode d'un BO qui utilise différentes stratégies pour calculer le salaire d'une personne. C'est un test unitaire à mon avis.

Answer 4

J'ai entendu parler de techniques dans lesquelles bon nombre des tests unitaires sont effectués en premier, puis développés autour d'eux. Quelqu'un vient de commenter en disant qu'il s'agit de "Test Driven Development". - TDD (Merci Elie).

Mais s'il s'agit d'une opération offshore qui risque de vous faire payer plus d'argent parce qu'ils passent du temps à faire ces tests unitaires, alors je ferais attention. Demandez un deuxième avis à une personne expérimentée dans les tests unitaires qui vérifiera qu'elle fait ce qu'elle dit.

À ma connaissance, les tests unitaires ajouteront un peu plus de temps à tout projet de développement, mais ils peuvent bien sûr offrir un contrôle de la qualité. Néanmoins, c’est le type de contrôle de qualité que je souhaiterais avec un projet interne. C’est peut-être quelque chose que la société offshore jette là-bas pour vous donner un sentiment flou.

Answer 5

Il existe une différence entre le processus que vous utilisez pour tester et la technologie utilisée pour le prendre en charge. Les divers frameworks utilisés pour les tests unitaires sont généralement très flexibles et peuvent être utilisés pour tester de petites unités de code, de grandes unités et même des tests de processus entiers. Cette flexibilité peut être source de confusion.

Ma recommandation est que, quelle que soit la méthode ou le processus spécifique que vous adoptiez, vous divisiez les différents tests unitaires en ensembles ou modules distincts. L'organisation exacte dépend de votre code et de l'organisation de votre entreprise.

L’effet cumulatif de l’utilisation de la structure de test unitaire est qu’une grande partie des tests du code est automatisée. Adoptés correctement, les développeurs peuvent mieux évaluer les modifications apportées au code sans passer par un processus complet de questions-réponses. En ce qui concerne le Q & amp; Un processus lui-même rend leur temps plus productif car la qualité du code issu du développement devrait être meilleure.

Comprenez que ce n’est pas LA solution à tous les problèmes de qualité, c’est un outil utile comme les autres que vous utilisez.

Answer 6

Wikipedia semblerait suggérer que le test unitaire consiste à tester le plus petit volume de code qui serait une méthode sur une classe dans le cas de la programmation OO.

Certains peuvent avoir un terme plus général de ce qu’ils entendent par tests unitaires, où certains peuvent penser que certains tests d’intégration sont des tests unitaires lorsque l’unité est un mélange de composants.

Answer 7

il existe une vue traditionnelle de http://en.wikipedia.org/wiki/Software_testing dans le cadre de http://en.wikipedia.org/wiki/Software_engineering . mais j'aime bien l'idée d'un test unitaire agile: un test est un test unitaire agile s'il est suffisamment rapide pour que les programmeurs le le lancent toujours.

Answer 8

Un test unitaire est la plus petite et la seule pièce de confiance que vous puissiez obtenir sur votre chemin. C’est ce qui importe: construire de manière itérative un bouclier contre la régression et les écarts de spécifications, et non pas la façon dont vous l’intègrerez réellement à votre architecture orientée objet.

Answer 9

Il s’agit presque de la répétition du " Qu'est-ce qu'une "unité"? " ; question.

"Unité" peut être défini de manière flexible. Si leur document ne contient pas de définition de "unité", vous devrez le préciser.

Il se peut qu’ils considèrent l’unité comme un grand assemblage de code. Ce qui n’est pas la définition la plus souhaitable.

Bien que je convienne que vous avez plusieurs couches de test (unité, module, package, application), je pense également que cela peut être en grande partie réalisé avec des outils de test unitaire. Conduisant à "Qu'est-ce qu'une unité?" questions à venir tout le temps.

L'unité dépend du contexte. Pour un développeur individuel, l'unité doit être classe. Parfois, cela signifie également module ou package.

Toutefois, pour une équipe, son unité peut être un package ou une application complète.

Answer 10

Qu'importe ce que nous pensons? Le problème ici est votre mécontentement avec les termes utilisés dans le document. Pourquoi n'en parlez-vous pas avec eux?

Answer 11

Il y a dix ans, avant l'utilisation actuelle du " test unitaire " comme tests écrits en code, la même désignation a été appliquée aux tests manuels. J'ai travaillé pour une entreprise de développement logiciel avec un processus de développement logiciel très formalisé. Nous avons dû écrire "tests unitaires". avant d'écrire un code. À cette époque, les tests unitaires étaient écrits dans un document texte (comme dans Word). Ils ont décrit les étapes exactes que l'utilisateur devait suivre pour utiliser l'application. Par exemple, ils ont décrit l’entrée exacte à taper sur la page pour configurer un nouveau client. Ou bien, l'utilisateur devait rechercher un produit particulier et voir que les informations affichées correspondaient au document de test. Donc, le test était un script que le testeur a suivi, où ils ont également enregistré les résultats. Lorsque la nouvelle incarnation des tests unitaires est arrivée, il a été difficile de savoir s’il s’agissait des tests anciens ou humains, ou des nouveaux tests codés.

Answer 12

Je dirige aussi un groupe d’équipes offshore. Supposons que nous ayons une série de tests unitaires ... mais cela ne veut pas dire grand chose. :) Nous comptons donc beaucoup plus sur la qualité des testeurs et des testeurs. Le problème inhérent aux tests unitaires est que vous avez une connaissance parfaite des fonctionnalités et que vous faites confiance aux développeurs. Dans le monde réel, c'est difficile à supposer.