Vous vous en approchez mal. Testez simplement vos fonctionnalités: si une exception est levée, le test échouera automatiquement. Si aucune exception n'est levée, vos tests deviendront tous verts.
J'ai remarqué que cette question suscite de temps en temps de l'intérêt, je vais donc m'étendre un peu.
Contexte des tests unitaires
Lorsque vous effectuez des tests unitaires, il est important de définir vous-même ce que vous considérez comme une unité de travail. Fondamentalement: une extraction de votre base de code qui peut ou non inclure plusieurs méthodes ou classes qui représente une seule fonctionnalité.
Ou, comme défini dans The art of Unit Testing, 2nd Edition by Roy Osherove , page 11:
Un test unitaire est un morceau de code automatisé qui appelle l'unité de travail testée, puis vérifie certaines hypothèses concernant un seul résultat final de cette unité. Un test unitaire est presque toujours écrit à l'aide d'un cadre de tests unitaires. Il peut être écrit facilement et s'exécute rapidement. Il est fiable, lisible et maintenable. Il est cohérent dans ses résultats tant que le code de production n'a pas changé.
Ce qui est important à réaliser, c'est qu'une unité de travail n'est généralement pas seulement une méthode mais au niveau très basique c'est une méthode et ensuite elle est encapsulée par une autre unité de travail.
Idéalement, vous devriez avoir une méthode de test pour chaque unité de travail séparée afin que vous puissiez toujours voir immédiatement où les choses vont mal. Dans cet exemple, il existe une méthode de base appelée getUserById()
qui retournera un utilisateur et il y a un total de 3 unités de travaux.
La première unité de travail doit tester si un utilisateur valide est retourné ou non dans le cas d'une entrée valide et invalide.
Toutes les exceptions levées par la source de données doivent être traitées ici: si aucun utilisateur n'est présent, un test doit démontrer qu'une exception est levée lorsque l'utilisateur est introuvable. Un exemple de ceci pourrait être celui IllegalArgumentException
qui est pris avec l' @Test(expected = IllegalArgumentException.class)
annotation.
Une fois que vous avez géré toutes vos valises pour cette unité de travail de base, vous montez d'un niveau. Ici, vous faites exactement la même chose, mais vous ne gérez que les exceptions qui viennent du niveau juste en dessous de l'actuel. Cela maintient votre code de test bien structuré et vous permet de parcourir rapidement l'architecture pour trouver où les choses tournent mal, au lieu d'avoir à sauter partout.
Gestion d'une entrée valide et défectueuse d'un test
À ce stade, il devrait être clair comment nous allons gérer ces exceptions. Il existe 2 types d'entrée: entrée valide et entrée défectueuse (l'entrée est valide au sens strict, mais elle n'est pas correcte).
Lorsque vous travaillez avec une entrée valide, vous définissez l'espérance implicite que le test que vous écrivez fonctionnera.
Un tel appel de méthode peut ressembler à ceci: existingUserById_ShouldReturn_UserObject
. Si cette méthode échoue (par exemple: une exception est levée), vous savez que quelque chose s'est mal passé et vous pouvez commencer à creuser.
En ajoutant un autre test ( nonExistingUserById_ShouldThrow_IllegalArgumentException
) qui utilise l' entrée défectueuse et attend une exception, vous pouvez voir si votre méthode fait ce qu'elle est censée faire avec une mauvaise entrée.
TL; DR
Vous essayiez de faire deux choses dans votre test: vérifier une entrée valide et défectueuse. En divisant cela en deux méthodes qui font chacune une chose, vous aurez des tests beaucoup plus clairs et une bien meilleure vue d'ensemble des problèmes.
En gardant à l'esprit l'unité de travail en couches, vous pouvez également réduire le nombre de tests dont vous avez besoin pour une couche plus élevée dans la hiérarchie, car vous n'avez pas à tenir compte de tout ce qui pourrait avoir mal tourné dans les couches inférieures: le les couches en dessous de la couche actuelle sont une garantie virtuelle que vos dépendances fonctionnent et si quelque chose ne va pas, c'est dans votre couche actuelle (en supposant que les couches inférieures ne génèrent aucune erreur elles-mêmes).