Quand un test n'est-il pas un test unitaire ?

Question

Je cherche des règles comme :

Un test n'est pas un test unitaire si :

• il communique avec une base de données
• il ne peut pas être exécuté en parallèle avec d'autres tests
• utilise l'"environnement" comme le registre ou le système de fichiers

Qu'y a-t-il d'autre ?

Answer 1

Ver Définition de Michael Feathers

Un test n'est pas un test unitaire si :

• Il communique avec la base de données
• Il communique à travers le réseau
• Il touche le système de fichiers
• Il ne peut pas être exécuté en même temps que d'autres tests unitaires.
• Vous devez effectuer des opérations spéciales sur votre environnement (comme la modification des fichiers de configuration) pour l'exécuter.

Answer 2

Un test n'est pas un test d'unité s'il ne teste pas une unité.

Sérieusement, c'est tout ce qu'il y a à faire.

Le concept d'"unité" dans les tests unitaires n'est pas bien défini, en fait, la meilleure définition que j'ai trouvée jusqu'à présent n'est pas vraiment une définition car elle est circulaire : une unité dans un test unitaire est la plus petite chose possible qui peut être testée de manière isolée.

Cela vous donne deux points de contrôle : est-il testé en isolation ? Et est-ce la plus petite chose possible ?

Veuillez noter que ces deux éléments dépendent du contexte. Ce qui pourrait être la plus petite chose possible dans une situation (disons, un objet entier) pourrait dans une autre situation n'être qu'un petit morceau d'une seule méthode. Et ce qui est considéré comme une isolation dans une situation peut l'être dans une autre (par exemple, dans un langage géré par la mémoire, on ne peut pas dire qu'il s'agisse d'une isolation. jamais fonctionnent de manière isolée du ramasseur de déchets, et la plupart du temps, cela n'est pas pertinent, mais parfois, cela peut ne pas l'être).

Answer 3

Il n'a pas d'assertion et ne s'attend pas à ce qu'une exception soit levée.

Answer 4

C'est difficile...

Pour moi, un test unitaire vérifie un élément spécifique de la logique de l'entreprise. isolement . En d'autres termes, je prends une certaine logique, je l'extrais du reste (si nécessaire en simulant des dépendances) et je teste uniquement cette logique - une unité (de l'ensemble) - en explorant différents types de flux de contrôle possibles.

Mais d'un autre côté, pouvons-nous toujours dire à 100% si c'est correct ou incorrect ? Sans vouloir devenir philosophe, mais - comme aussi Michael dit dans son poste :

Les tests qui le font ces choses ne sont pas mauvaises. Souvent, ils valent la peine d'être écrits et ils peuvent être écrits dans un harnais de tests unitaires. Cependant, il est important de pouvoir les les séparer des véritables tests unitaires afin que nous puissions garder un ensemble de tests que nous pouvons exécuter rapidement chaque fois que nous changements.

Alors pourquoi ne pourrais-je pas écrire un test unitaire qui vérifie la logique de l'analyse d'un fichier xls, par exemple, en accédant à un fichier factice du système de fichiers dans mon dossier de test (comme les tests MS le permettent avec le DeploymentItem) ?

Bien sûr - comme mentionné - nous devrions séparer ce type de tests des autres (peut-être dans une suite de tests séparée dans JUnit). Mais je pense que l'on devrait aussi écrire ces tests si l'on se sent à l'aise de les avoir là... clairement, en se rappelant toujours qu'un test unitaire doit juste tester une pièce de manière isolée.

Le plus important à mes yeux est que ces tests fonctionnent rapidement et ne prennent pas trop de temps s.t. Ils peuvent être exécutés de manière répétée et très souvent.

Answer 5

Un test n'est pas un test unitaire lorsque :

• il teste plus d'une chose à la fois (c'est-à-dire qu'il teste comment deux choses fonctionnent ensemble) - alors c'est un test d'intégration

Liste de contrôle pour de bons tests unitaires :

• ils sont automatisés
• ils sont reproductibles
• ils sont faciles à mettre en œuvre
• ils restent pour une utilisation future, une fois écrits
• ils peuvent être gérés par n'importe qui
• ils peuvent être actionnés par la pression d'un bouton
• ils courent rapidement

Quelques bonnes pratiques supplémentaires (sans ordre particulier d'importance) :

• les tests doivent être séparés des tests d'intégration (qui sont plus lents), afin qu'ils puissent être exécutés rapidement aussi souvent que possible
• ils ne doivent pas comporter trop de logique (de préférence, pas de structures de contrôle)
• chaque test ne doit tester qu'une seule chose (donc, ils ne doivent contenir qu'une seule assert)
• les valeurs attendues utilisées dans les assertions doivent être codées en dur et non calculées au moment de l'exécution du test
• Les dépendances externes (système de fichiers, temps, mémoire, etc.) doivent être remplacées par des stubs.
• Le test doit recréer l'état initial à l'arrêt du test.
• dans les assertions, il est préférable d'utiliser une politique "contient...", plutôt que "est strictement égal..." (c'est-à-dire que nous attendons certaines valeurs dans une collection, certains caractères dans une chaîne, etc.)

C'est une partie des connaissances que j'ai extraites du livre de Roy Osherove - L'art des tests unitaires