assertThat, assertEquals, assertTrue

Hier soir, c'était l'événement portes ouvertes d'AgileChina 2011, et j'étais bénévole lors de la session de codage. L'objectif principal de la session de codage est de permettre aux développeurs participants d'expérimenter le processus de programmation en binôme, de développement piloté par les tests et de refactoring. Nous avons préparé quatre types différents de questions de programmation. Huit ou neuf collègues de l'entreprise et pairs participants expérimenteront ensemble ce processus :

Feuille de temps

Caisse du supermarché

Statistiques de lignes de code source

Jeu de Blackjack

Dans l'ensemble, l'événement a été plutôt réussi, à l'exception de deux petits épisodes :

1 La société voulait que j'achète un nouveau clavier et une nouvelle souris. , mais ils sont trop tactiles lors de la frappe et les touches du clavier sont plates. Un participant peut ne pas être très familier avec le clavier et taper toujours par erreur dans une barre oblique à plusieurs reprises.

2. Les touches de raccourci de l'écran de verrouillage du système sont en conflit avec les touches de raccourci du code de formatage de l'EDI, ce qui m'a amené à taper deux fois la mauvaise touche pour verrouiller l'écran. De plus, la machine ne m'appartient pas, je l'ai donc fait. pour trouver d'autres collègues pour m'aider à le saisir, bon sang.

Lors du dernier tour de Pair, un étudiant a demandé : Pourquoi ne pas utiliser assertEquals ? Je vois que vous utilisez tous assertThat, et il semble que l'utilisation de assertEquals, assertTrue, etc. ne soit pas fortement recommandée.

Comme l'événement était presque terminé et que nous allions prendre une photo de groupe, nous avons simplement répondu. Voici une réponse détaillée à cette question.

Que voulons-nous obtenir des assertions

Que voulons-nous obtenir des assertions dans les tests ? Afficher simplement une barre rouge après l'échec d'un test n'est pas ce que nous souhaitons. De plus, nous souhaitons également obtenir des informations sur le test :

1. Où le test échoue-t-il ? Toutes les assertions peuvent fournir cette fonction

2. La raison pour laquelle le test a échoué est difficile à définir. La plupart des assertions peuvent fournir des fonctionnalités similaires :

Résultat attendu par rapport au résultat réel

Mais différentes assertions fournissent des informations différentes. Il existe également des problèmes où les comparaisons sont difficiles à faire à partir d’affirmations simples comme l’égalité. De plus, les assertions ont également un rôle très important : la documentation. Autrement dit, lorsque vous lisez le code du test, vous voyez les assertions comme si vous voyiez toutes les attentes. Et des attentes très claires.

Exemple réel

Regardez le deuxième paramètre de assertThat. Il accepte un Matcher. Il existe des implémentations très riches de Matcher dans org.hamcrest. Par exemple, notre API renvoie désormais une liste d'objets utilisateur. Nous voulons affirmer que cette liste contient l'utilisateur attendu. Il existe un Matcher tel que hasItem dans hamcrest :

   1: assertThat(userDAO.findAll(), hasItem(expected));

Que faire si autre. les assertions sont utilisées ?

   1: assertTrue(userDAO.findAll().contains(expected));

D'accord, voici le problème, si les deux assertions ci-dessus échouent, le message d'échec de la première assertion sera :

Le résultat attendu contient attendu….

Mais en fait... tous les utilisateurs renvoyés par findAll seront imprimés

Et qu'en est-il de la deuxième assertion ? C'est comme ça :

On s'attendait à ce qu'il soit vrai, en fait faux

Lequel est le plus fiable ? Évidemment, les informations d'échec de la première assertion nous sont plus utiles pour trouver le problème.

Pour la documentation, regardons cette exigence : Affirmer que la liste d'utilisateurs renvoyée ne contient pas un utilisateur donné :

   1: assertThat(userDAO.findAll(), not(hasItem(expected));

N'est-ce pas très clair ? Vous ne lirez pas ceci ? assertion Vous aurez l'impression de lire du code, tout comme vous lisez Spec. Si d'autres assertions sont utilisées :

   1: assertFalse(userDAO.findAll().contains(expected));

ne sont pas aussi bien documentées que la précédente.

Bien sûr, pour certaines API qui renvoient vrai ou faux, ou renvoient une seule valeur, vous pouvez également utiliser d'autres assertions sans trop de problème. Par exemple :

   1: assertEquals(userDAO.findBy(id), expected);

Ah, quoi ? Tu as dit que je l'avais mal utilisé, pourquoi ? Après avoir vérifié la description du paramètre, j'ai constaté que la valeur attendue devait être placée dans le premier paramètre et que la valeur réelle devait être placée dans le deuxième paramètre. C'est tellement impuissant. Ma mémoire n'est pas bonne et je fais toujours des erreurs. Heureusement, nous avons affirmé que :

   1: assertThat(userDAO.findBy(id), is(expected));

Ferez-vous encore des erreurs ?

Ce qui précède est le contenu de assertThat, assertEquals, assertTrue Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !