esprit d'un test JUnit

Question

Supposons que vous ayez la logique suivante en place:

processMissing(masterKey, masterValue, p.getPropertiesData().get(i).getDuplicates()); 

public StringBuffer processMissing(String keyA, String valueA, Set<String> dupes) { 
// do some magic 
} 

Je voudrais écrire un test JUnit pour processMissing, tester son comportement en cas dupant est nul.

Est-ce que je fais la bonne chose ici? Dois-je vérifier comment la méthode gère sous null, ou peut-être tester la méthode call pour s'assurer que null n'est jamais envoyé?

D'une manière générale, quelle est l'approche ici? Nous ne pouvons pas tout tester pour tout. Nous ne pouvons pas non plus gérer tous les cas possibles. Comment devrait-on penser au moment de décider quels tests écrire?

Je pensais comme ceci:

1. J'ai une certaine attente avec la méthode
2. test doit confirmer définir mes attentes et confirmer méthode fonctionne sous cette condition

Est-ce la bonne façon d'y penser?

Merci et s'il vous plaît laissez-moi savoir

Answer 1

D'abord, définissez si null est une valeur valide pour le paramètre ou non.

Si c'est le cas, alors oui, tester définitivement le comportement de la méthode avec null.

Dans le cas contraire, alors:

• Précisons que la contrainte par la documentation des paramètres.
• Annoter cette contrainte sur le paramètre lui-même (à l'aide d'une annotation compatible avec l'outil ci-dessous).
• Utilisez un outil d'analyse statique pour vérifier que null n'est jamais transmis.
• Aucun test unitaire n'est requis pour la valeur non valide sauf si vous écrivez du code pour le vérifier.

L'outil d'analyse statique FindBugs prend en charge les annotations telles que @NonNull, avec une analyse de flux de données limitée.

Personnellement, je pense qu'il serait inutilement coûteux au sein de grandes bases de code Java à toujours d'écrire et de maintenir des vérifications explicites pour NULL et les tests unitaires non locaux correspondants.

Answer 2

Si vous voulez vous assurer que les gens ne remettent pas votre API avec un argument null, vous voudrez peut-être envisager d'utiliser des annotations pour en faire explicitement, JSR 305 couvre cela, et son utilisé à Goyava. Sinon, vous comptez sur les utilisateurs qui lisent javadoc. En ce qui concerne les tests, vous ne pouvez pas gérer tous les cas possibles, à supposer que vous ne souhaitiez pas prendre en charge les valeurs nulles, je dirais que vous pouvez lancer une exception IllegalArguemntException plutôt qu'une NullPointerException afin que vous puissiez être explicite sur ce qui est null, alors vous pouvez simplement tester si cette exception est levée - voir JUnit docs.