Angular

Appearance

Terminologie ​

Un Stub et Mock ​

Un stub est une fonction utilisée dans les tests unitaires pour remplacer une fonction dépendante dans le code que vous voulez tester. Cela vous permet de contrôler le comportement de la fonction dépendante pendant le test.

Voici un exemple pour vous aider à comprendre :

Imaginons que vous ayez une application de commande de nourriture en ligne. Vous voulez tester la fonction qui calcule le coût total de la commande en fonction des articles sélectionnés et des prix actuels des articles. Cependant, la fonction qui obtient les prix actuels des articles dépend d'une API externe qui peut ne pas être disponible ou stable pendant le test.

Dans ce cas, vous pouvez créer un stub pour remplacer la fonction qui obtient les prix actuels des articles. Vous pouvez définir ce que le stub renvoie pour les différents articles, afin de tester le comportement de la fonction qui calcule le coût total de manière cohérente et fiable.

Un mock est également une fonction utilisée dans les tests unitaires, mais il est plus spécifique qu'un stub. Un mock remplace une dépendance pour vérifier comment elle est utilisée au cours d'un test plutôt que simplement de contrôler son comportement.

Imaginons que vous ayez une application de messagerie. Vous voulez tester la fonction qui envoie un message à un destinataire. Cependant, la fonction qui envoie le message dépend d'un service de messagerie externe qui peut ne pas être disponible ou stable pendant le test.

Dans ce cas, vous pouvez créer un mock pour remplacer la fonction qui envoie le message. Vous pouvez définir ce que le mock fait lorsqu'il est appelé, par exemple, enregistrer les arguments qui lui ont été transmis ou incrémenter un compteur. Ce faisant, vous pouvez vérifier que la fonction qui envoie le message appelle correctement le service de messagerie externe avec les bonnes informations.

Les stubs et les mocks sont tous deux des objets factices pour les tests, alors que les stubs n'implémentent qu'une réponse préprogrammée, les mocks préprogramment également des attentes spécifiques.

Qu'est qu'un dummy, fake et spy dans ? ​

Un dummy est un objet ou une fonction factice utilisé dans les tests unitaires pour remplacer une dépendance ou une entrée de données nécessaire pour exécuter un test, mais qui n'a pas besoin d'avoir une valeur ou un comportement spécifique. Le but principal d'un dummy est de remplir une exigence minimale pour que le test puisse être exécuté.

Un fake est une implémentation factice d'une dépendance qui a un comportement spécifique et prédéterminé pour les tests. Le but principal d'un fake est de remplacer une dépendance pour contrôler son comportement lorsque le test est exécuté.

Un spy est une fonction qui enregistre comment elle est appelée, comme les arguments qui lui ont été transmis et combien de fois elle a été appelée. Les espions sont souvent utilisés pour vérifier comment une dépendance est utilisée au cours d'un test.

Imaginons que vous ayez une application pour gérer les tâches quotidiennes. Vous voulez tester la fonction qui ajoute une nouvelle tâche à la liste. Cependant, la fonction dépend d'une base de données pour stocker les tâches.

Dans ce cas, vous pouvez utiliser un dummy pour remplacer la base de données. Vous n'avez pas besoin de vérifier comment la base de données est utilisée, vous voulez simplement vous assurer que la fonction ajoute correctement une nouvelle tâche à la liste.

Vous pouvez également utiliser un fake pour remplacer la base de données si vous voulez vérifier comment la fonction ajoute une nouvelle tâche à la liste en fonction de la réponse de la base de données. Vous pouvez définir ce que le fake renvoie pour différentes entrées, afin de tester le comportement de la fonction dans différentes situations.

Enfin, vous pouvez utiliser un espion pour remplacer la base de données si vous voulez vérifier combien de fois la fonction ajoute une nouvelle tâche à la liste et avec quelles entrées. Les informations enregistrées par l'espion peuvent vous aider à déterminer si la fonction appelle correctement la base de données avec les bonnes informations.Terminologie

Coverage ? ​

Le "coverage" est un terme utilisé pour décrire la quantité de code de votre application qui a été testé par vos tests unitaires. Plus précisément, cela mesure la proportion de lignes de code, de conditions et d'autres éléments qui ont été exécutés au moins une fois lors de l'exécution des tests unitaires.

Imaginons que vous ayez écrit une application pour gérer les tâches quotidiennes. Vous voulez vous assurer que toutes les parties de votre application sont testées et fonctionnent correctement. Vous pouvez utiliser un outil de coverage pour mesurer la quantité de code de votre application qui a été couvert par les tests unitaires.

Si vous trouvez que certaines parties de votre code ne sont pas couvertes par les tests, vous pouvez écrire des tests supplémentaires pour les couvrir. Ainsi, vous pouvez être sûr que votre application fonctionne correctement, même lorsqu'elle est mise à jour ou modifiée. Le coverage est donc un indicateur utile pour savoir à quel point votre code est testé et peut vous aider à déterminer les parties de votre application qui nécessitent des tests supplémentaires.

Qu'est qu'un test d'intégration ? ​

Un test d'intégration est un type de test qui vérifie comment différentes parties de votre application interagissent les unes avec les autres. Il s'agit d'une étape importante pour s'assurer que votre application fonctionne correctement lorsque toutes les parties sont utilisées ensemble.

Un test unitaire, quant à lui, est un test qui vérifie le fonctionnement d'une seule partie ou fonctionnalité de votre application. Les tests unitaires sont généralement plus petits et plus rapides à exécuter que les tests d'intégration, et ils se concentrent sur une fonctionnalité spécifique.

Imaginons que vous ayez une application qui gère les commandes de pizzas. Les tests unitaires peuvent vérifier si chaque ingrédient peut être ajouté à la commande, si le prix est calculé correctement pour chaque ingrédient, et si le temps de livraison est correctement affiché. Les tests d'intégration, quant à eux, peuvent vérifier si l'application fonctionne correctement lorsque toutes les parties sont utilisées ensemble, par exemple en vérifiant si la commande est correctement enregistrée dans la base de données et si elle peut être récupérée et affichée plus tard.

Qu'est qu'un test e2e ? ​

Un test end-to-end, ou test e2e, est un type de test qui vérifie comment une application fonctionne lorsqu'elle est utilisée par un utilisateur final. Il s'agit d'une étape importante pour s'assurer que votre application fonctionne correctement lorsque toutes les parties sont utilisées ensemble.

Imaginons que vous ayez une application de e-commerce. Les tests e2e peuvent vérifier le processus complet d'achat d'un produit, de la recherche de celui-ci à l'ajout au panier, au paiement et à la livraison. Cela permet de s'assurer que toutes les fonctionnalités de l'application fonctionnent correctement ensemble, comme cela se produirait lorsqu'un utilisateur réel utilise l'application.

Quelles sont les bonnes pratiques pour écrire un tests unitaires ? ​

  1. Testez une seule chose à la fois : Assurez-vous que chaque test vérifie une seule chose à la fois. Cela rend les tests plus simples à comprendre et plus faciles à maintenir.

  2. Écrivez des tests indépendants : Chaque test doit pouvoir être exécuté indépendamment des autres sans affecter leurs résultats.

  3. Écrivez des tests pour tous les scénarios : Écrivez des tests pour couvrir tous les scénarios possibles, y compris les cas d'erreur.

  4. Nommez les tests clairement : Les noms des tests doivent décrire clairement ce qui est testé.

  5. Utilisez un framework de test : Il existe de nombreux frameworks de test pour JavaScript, tels que Jest, Jasmine, Mocha, qui vous aident à écrire et à exécuter des tests.

Approche TDD ou BDD ? ​

TDD signifie "Test Driven Development", qui est une méthode de développement de logiciel dans laquelle vous écrivez d'abord les tests pour votre code avant de l'écrire réellement. En d'autres termes, vous testez d'abord votre code pour vous assurer qu'il fonctionne correctement avant de le développer. Cela vous aide à mieux comprendre les exigences du projet et à écrire du code plus propre et plus organisé.

Imaginons que vous voulez développer une calculatrice simple qui peut effectuer des opérations de base telles que l'addition et la soustraction. Avec TDD, vous commencerez par écrire les tests pour vérifier que l'addition et la soustraction fonctionnent correctement. Ensuite, vous écririe l'implémentation de la calculatrice pour satisfaire ces tests.

BDD signifie "Behavior Driven Development", qui est une autre approche pour le développement de logiciels axée sur les comportements attendus du système plutôt que sur les tests en eux-mêmes. BDD se concentre sur la communication entre les développeurs, les testeurs et les utilisateurs pour s'assurer que les exigences sont bien compris et que le code développé correspond aux attentes.

Imaginons que vous voulez développer une application pour gérer les tâches quotidiennes. Avec BDD, vous commencerez par discuter avec les utilisateurs pour comprendre leurs besoins et les comportements attendus de l'application. Ensuite, vous écririez des scénarios qui décrivent comment l'application devrait se comporter pour satisfaire ces attentes. Enfin, vous développeriez l'application pour satisfaire ces scénarios. Cela peut également améliorer la qualité du logiciel et faciliter la communication entre les différentes équipes.

Technique des test unitaires: arrange, act, assert ​

Les tests unitaires sont une technique utilisée pour vérifier le comportement individuel des unités de code, telles que les fonctions, dans une application. La technique "arrange, act, assert" est un moyen simple et courant de structurer ces tests.

  1. Arrange: C'est la première étape dans laquelle vous configurez les conditions nécessaires pour effectuer le test. Cela peut inclure la création d'objets, la définition de valeurs, etc.

  2. Act: C'est la deuxième étape où vous appelez la fonction que vous souhaitez tester.

  3. Assert: C'est la dernière étape où vous vérifiez que la fonction a retourné les résultats attendus. Si les résultats correspondent à ce que vous attendiez, le test est considéré comme réussi. Si ce n'est pas le cas, le test échoue et vous pouvez corriger les erreurs de votre code.

Exemple:

js
function add(a, b) {
  return a + b;
}

test('adds 1 + 2 to equal 3', () => {
  // Arrange
  const a = 1;
  const b = 2;

  // Act
  const result = add(a, b);

  // Assert
  expect(result).toBe(3);
});
function add(a, b) {
  return a + b;
}

test('adds 1 + 2 to equal 3', () => {
  // Arrange
  const a = 1;
  const b = 2;

  // Act
  const result = add(a, b);

  // Assert
  expect(result).toBe(3);
});

Dans cet exemple, nous avons une fonction simple add qui prend en entrée deux nombres et renvoie leur somme. Le test utilise Jest pour vérifier que lorsque nous passons 1 et 2 à la fonction add, nous obtenons un résultat de 3. Nous utilisons la méthode expect pour faire cette vérification et toBe pour vérifier si la valeur est égale à la valeur attendue.