Tests unitaires - Exemples de code pour illustrer ce qui devrait/ne devrait pas être testé au niveau de la classe/méthode.

Question

J'ai lu les rubriques connexes sur le Web, y compris ce site. Mais je ne peux pas en trouver un avec beaucoup de code pour expliquer le sujet en question. Je pratique le TDD et les tests unitaires depuis un certain temps. Je veux savoir ce qui devrait et ne devrait pas être testé unitairement en termes de niveau de classe, de niveau de méthode. Par exemple, dois-je tester tout (à quoi sert le test d'intégration)? Dans une méthode cible, quelles lignes de code dois-je tester unitairement? Y a-t-il de bons principes et de bonnes pratiques dans ce domaine, ou de bons supports de lecture avec beaucoup d'exemples de code à illustrer?

Le sujet ici concerne le langage côté serveur, par ex. C#, Java.

Mise à jour

S'il vous plaît noter que les livres ci-dessous ne couvrent pas ce que je cherche (si je ne me trompe pas)

Pragmatic Unit Testing

Art of Unit Testing

Answer 1

D'une manière générale, l'unité les tests devraient être des tests en boîte blanche, les tests d'intégration devraient être en boîte noire. C'est-à-dire qu'un test unitaire doit s'appuyer sur le fonctionnement interne d'une unité de code, généralement une méthode. En tant que développeur, vous inspecteriez les chemins d'exécution possibles à travers la méthode et créeriez un cas de test pour chacun d'eux. Un test unitaire devrait également tester la méthode isolément. Tout collaborateur ou entrée et sortie doit être raillé, de sorte que seule la méthode testée est exécutée par le test unitaire.

Pour trouver les chemins d'exécution, vous devez réfléchir aux entrées possibles pour une méthode et aux branches (par exemple if instructions et exceptions). Par exemple

public boolean isYes() { 
    return someValue.equals("yes"); 
} 

Cette méthode n'a pas if déclarations contenues dans, mais il a trois voies d'exécution.

• Si someValue est "yes" alors la méthode retourne true
• Si someValue est une autre chaîne comme "Yes", "no", "bananas" ou "" retourne false
• Si someValue est null il jette un NullPointerException

Dans ce cas, penser à propos de ces chemins d'exécution et d'écrire des tests unitaires pour couvrir ces cas vous aide à réfléchir à quels problèmes il pourrait y avoir avec la méthode.

Un test où le chemin d'exécution visiterait plusieurs unités de code serait un test d'intégration. Vous exécuteriez le test en termes d'entrées et de sorties globales. Vous ne vous souciez pas comment cela fonctionne, juste cela fonctionne. Personnellement, je créerais des tests unitaires basés sur mes propres connaissances de la base de code, et pour chaque méthode individuellement.Je créerais des tests d'intégration basés sur des spécifications et des critères d'acceptation individuels à partir des exigences.

Answer 2

Pragmatic Unit Testing n'est pas le meilleur de la série Pragamatic et les techniques nunit étaient assez légères et datées quand je l'ai lu il y a des années. MAIS c'est assez bon marché et couvre les principes et les pratiques.

Art of Unit Testing est également une lecture utile.

Cheers,
Berryl