Où est la limite entre la logique d'application des tests unitaires et les constructions de langage méfiantes?

Considérons une fonction comme celle-ci:

function savePeople(dataStore, people) {
    people.forEach(person => dataStore.savePerson(person));
}

Cela pourrait être utilisé comme ceci:

myDataStore = new Store('some connection string', 'password');
myPeople = ['Joe', 'Maggie', 'John'];
savePeople(myDataStore, myPeople);

Laissez - nous supposer que Storea ses propres tests unitaires ou est fourni par le fournisseur. En tout cas, nous avons confiance Store. Et supposons en outre que la gestion des erreurs - par exemple, des erreurs de déconnexion de base de données - n’est pas de la responsabilité de savePeople. En effet, supposons que le magasin lui - même est une base de données magique qui ne peut en aucun cas se tromper. Compte tenu de ces hypothèses, la question est la suivante:

Devraient savePeople()être testés à l'unité, ou de tels tests équivaudraient-ils à tester la forEachstructure de langage intégrée ?

Nous pourrions, bien sûr, passer en faux dataStoreet affirmer que l’ dataStore.savePerson()on appelle une fois pour chaque personne. Vous pouvez certainement faire valoir qu'un tel test offre une sécurité contre les modifications d'implémentation: par exemple, si nous décidons de remplacer forEachpar une forboucle traditionnelle ou par une autre méthode d'itération. Donc, le test n'est pas entièrement trivial. Et pourtant, cela semble terriblement proche ...

Voici un autre exemple qui pourrait être plus fructueux. Considérons une fonction qui ne fait que coordonner d'autres objets ou fonctions. Par exemple:

function bakeCookies(dough, pan, oven) {
    panWithRawCookies = pan.add(dough);
    oven.addPan(panWithRawCookies);
    oven.bakeCookies();
    oven.removePan();
}

Comment une fonction comme celle-ci devrait-elle être testée par unité, à supposer que vous pensiez qu'elle le devrait? Il est difficile pour moi d'imaginer tout type de test unitaire qui ne se moque pas seulement dough, panet oven, puis affirment que les méthodes sont appelées sur eux. Mais un tel test ne fait que dupliquer la mise en oeuvre exacte de la fonction.

Cette incapacité à tester la fonction de manière explicite dans une boîte noire indique-t-elle un défaut de conception avec la fonction elle-même? Si oui, comment pourrait-il être amélioré?

Pour clarifier encore la question qui motive l' bakeCookiesexemple, je vais ajouter un scénario plus réaliste, celui que j'ai rencontré lors de la tentative d'ajout de tests et de refactorisation du code hérité.

Lorsqu'un utilisateur crée un nouveau compte, un certain nombre de choses doivent se produire: 1) un nouvel enregistrement d'utilisateur doit être créé dans la base de données 2) un courrier électronique de bienvenue doit être envoyé 3) l'adresse IP de l'utilisateur doit être enregistrée pour fraude fins.

Nous voulons donc créer une méthode qui relie toutes les étapes du "nouvel utilisateur":

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.insertUserRecord(validateduserData);
  emailService.sendWelcomeEmail(validatedUserData);
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

Notez que si l'une de ces méthodes génère une erreur, nous voulons que l'erreur apparaisse jusqu'au code appelant, de sorte qu'elle puisse la gérer comme elle l'entend. S'il est appelé par le code de l'API, il peut traduire l'erreur en un code de réponse http approprié. Si elle est appelée par une interface Web, l'erreur peut être traduite en un message approprié à afficher pour l'utilisateur, etc. Le fait est que cette fonction ne sait pas comment gérer les erreurs qui peuvent être générées.

L'essence de ma confusion est que, pour tester un peu une telle fonction, il semble nécessaire de répéter la mise en œuvre exacte dans le test lui-même (en précisant que les méthodes sont appelées dans un certain ordre), ce qui semble faux.

Devrait savePeople()être testé en unité? Oui. Vous ne testez pas que cela dataStore.savePersonfonctionne, ou que la connexion à la base de données fonctionne, ou même que cela foreachfonctionne. Vous testez que vous savePeopleremplissez la promesse faite dans le cadre de votre contrat.

Imaginez ce scénario: quelqu'un fait un grand refactor de la base de code et supprime accidentellement la forEachpartie de l'implémentation afin qu'elle enregistre toujours uniquement le premier élément. Voulez-vous pas un test unitaire pour attraper cela?

Habituellement, ce genre de question se pose lorsque les gens font du développement "après test". Abordez ce problème du point de vue de TDD, où les tests viennent avant l’implémentation, et posez-vous à nouveau cette question à titre d’exercice.

Au moins dans mon application de TDD, qui est généralement de l'extérieur, je ne mettrais pas en œuvre une fonction comme savePeopleaprès l'avoir implémentée savePerson. Les fonctions savePeopleet savePersondémarrent comme une seule et sont testées à partir des mêmes tests unitaires; la séparation entre les deux se produirait après quelques tests, dans l'étape de refactoring. Ce mode de travail poserait également la question de savePeoplesavoir quelle devrait être la fonction - que ce soit une fonction libre ou une partie de la dataStore.

En fin de compte , les tests ne seraient pas seulement vérifier si vous pouvez correctement enregistrer un Personen Store, mais aussi beaucoup de personnes. Cela me conduirait également à me demander si d'autres vérifications sont nécessaires, par exemple, "Dois-je m'assurer que la savePeoplefonction est atomique, en sauvegardant tout ou rien?", "Peut-il simplement renvoyer des erreurs aux personnes qui ne pourraient pas ' t être sauvé? Comment ressembleraient ces erreurs? ", et ainsi de suite. Tout cela représente bien plus que la simple vérification de l’utilisation d’une forEachou d’autres formes d’itération.

Cependant, si l'exigence de sauver plusieurs personnes à la fois ne s'imposait qu'après avoir savePersonété livrée, je mettrais alors à jour les tests existants savePersonpour exécuter la nouvelle fonction savePeople, en veillant à ce qu'elle puisse toujours sauver une personne en déléguant simplement au début, testez ensuite le comportement de plus d'une personne à travers de nouveaux tests, en vous demandant s'il serait nécessaire de rendre le comportement atomique ou non.

SavePeople () doit-il être testé par unité

Oui, ça devrait. Mais essayez d’écrire vos conditions de test d’une manière indépendante de la mise en oeuvre. Par exemple, convertissez votre exemple d'utilisation en test unitaire:

function testSavePeople() {
    myDataStore = new Store('some connection string', 'password');
    myPeople = ['Joe', 'Maggie', 'John'];
    savePeople(myDataStore, myPeople);
    assert(myDataStore.containsPerson('Joe'));
    assert(myDataStore.containsPerson('Maggie'));
    assert(myDataStore.containsPerson('John'));
}

Ce test fait plusieurs choses:

• il vérifie le contrat de la fonction savePeople()
• il ne se soucie pas de la mise en œuvre de savePeople()
• il documente l'exemple d'utilisation de savePeople()

Prenez note que vous pouvez toujours simuler / tronquer / simuler le magasin de données. Dans ce cas, je ne vérifierais pas les appels de fonction explicites, mais le résultat de l'opération. De cette façon, mon test est préparé pour les modifications / refacteurs futurs.

Par exemple, votre implémentation de magasin de données pourrait fournir une saveBulkPerson()méthode dans le futur. Désormais, une modification de l'implémentation savePeople()à utiliser saveBulkPerson()n'interromprait pas le test unitaire tant qu'elle saveBulkPerson()fonctionnerait comme prévu. Et si d'une saveBulkPerson()manière ou d'une autre ne fonctionne pas comme prévu, votre test unitaire le détectera.

ou de tels tests équivaudraient-ils à tester la construction de langage forEach intégrée?

Comme cela a été dit, essayez de tester les résultats attendus et l'interface de fonction, mais pas d'implémentation (à moins que vous ne fassiez des tests d'intégration - il pourrait alors être utile de capturer des appels de fonction spécifiques). S'il existe plusieurs façons d'implémenter une fonction, elles doivent toutes fonctionner avec votre test unitaire.

En ce qui concerne votre mise à jour de la question:

Testez les changements d'état! Par exemple, une partie de la pâte sera utilisée. Selon votre implémentation, affirmez que la quantité d’utilisé doughconvient panou affirme que le doughest épuisé. Vérifiez que le pancontient des cookies après l'appel de la fonction. Assure que le ovenest vide / dans le même état que précédemment.

Pour des tests supplémentaires, vérifiez les cas de bord: Que se passe-t-il si le ovenn'est pas vide avant l'appel? Que se passe-t-il s'il n'y en a pas assez dough? Si le panest déjà plein?

Vous devriez pouvoir déduire toutes les données requises pour ces tests à partir des objets de pâte, de casserole et de four eux-mêmes. Pas besoin de capturer les appels de fonction. Traitez la fonction comme si sa mise en œuvre ne serait pas disponible!

En fait, la plupart des utilisateurs de TDD écrivent leurs tests avant d’écrire la fonction, ils ne dépendent donc pas de la mise en oeuvre réelle.

Pour votre dernier ajout:

Lorsqu'un utilisateur crée un nouveau compte, un certain nombre de choses doivent se produire: 1) un nouvel enregistrement d'utilisateur doit être créé dans la base de données 2) un courrier électronique de bienvenue doit être envoyé 3) l'adresse IP de l'utilisateur doit être enregistrée pour fraude fins.

Nous voulons donc créer une méthode qui relie toutes les étapes du "nouvel utilisateur":

function createNewUser(validatedUserData, emailService, dataStore) {
    userId = dataStore.insertUserRecord(validateduserData);
    emailService.sendWelcomeEmail(validatedUserData);
    dataStore.recordIpAddress(userId, validatedUserData.ip);
}

Pour une fonction comme celle-ci, je me moquerais de / stub / fake (tout ce qui semble plus général) des paramètres dataStoreet emailService. Cette fonction ne fait aucune transition d'état sur aucun paramètre, elle les délègue aux méthodes de certains d'entre eux. Je voudrais essayer de vérifier que l'appel à la fonction a fait 4 choses:

• il a inséré un utilisateur dans le magasin de données
• il a envoyé (ou au moins appelé la méthode correspondante) un email de bienvenue
• il a enregistré l'adresse IP des utilisateurs dans le magasin de données
• il a délégué toute exception / erreur rencontrée (le cas échéant)

Les 3 premières vérifications peuvent être effectuées avec des faux, des moignons ou des faux ( dataStoreet emailServicevous ne voulez vraiment pas envoyer de courriels lors des tests). Depuis que j'ai dû chercher ceci pour certains commentaires, ce sont les différences:

• Un faux est un objet qui se comporte de la même manière que l'original et qui, dans une certaine mesure, est indiscernable. Son code peut normalement être réutilisé à travers les tests. Cela peut, par exemple, être une simple base de données en mémoire pour un wrapper de base de données.
• Un tronçon implémente simplement autant que nécessaire pour effectuer les opérations requises de ce test. Dans la plupart des cas, un talon est spécifique à un test ou à un groupe de tests ne nécessitant qu'un petit ensemble des méthodes de l'original. Dans cet exemple, il peut s'agir d'une application dataStorequi implémente simplement une version appropriée de insertUserRecord()and recordIpAddress().
• Un mock est un objet qui vous permet de vérifier son utilisation (le plus souvent en vous permettant d'évaluer les appels à ses méthodes). J'essayerais de les utiliser avec parcimonie dans les tests unitaires car en les utilisant, vous essayez en fait de tester la mise en œuvre de la fonction et non l'adhérence de son interface, mais ils ont toujours leurs utilisations. Il existe de nombreux cadres de simulation pour vous aider à créer exactement le modèle dont vous avez besoin.

Notez que si l'une de ces méthodes génère une erreur, nous voulons que l'erreur apparaisse jusqu'au code appelant, de sorte qu'elle puisse la gérer comme elle l'entend. S'il est appelé par le code de l'API, cela peut traduire l'erreur en un code de réponse HTTP approprié. Si elle est appelée par une interface Web, l'erreur peut être traduite en un message approprié à afficher pour l'utilisateur, etc. Le fait est que cette fonction ne sait pas comment gérer les erreurs qui peuvent être générées.

Les exceptions / erreurs attendues sont des cas de test valides: vous confirmez que, si un tel événement se produit, la fonction se comporte comme prévu. Cela peut être réalisé en laissant l'objet simulé / faux / tronqué jeté lorsque vous le souhaitez.

L'essence de ma confusion est que, pour tester un peu une telle fonction, il semble nécessaire de répéter la mise en œuvre exacte dans le test lui-même (en précisant que les méthodes sont appelées dans un certain ordre), ce qui semble faux.

Parfois, cela doit être fait (même si cela vous tient particulièrement à cœur lors des tests d'intégration). Le plus souvent, il existe d'autres moyens de vérifier les effets secondaires / changements d'état attendus.

La vérification des appels de fonctions exactes donne lieu à des tests unitaires plutôt fragiles: seuls de petits changements apportés à la fonction d'origine entraînent leur échec. Cela peut être souhaité ou non, mais cela nécessite une modification du ou des tests unitaires correspondants chaque fois que vous modifiez une fonction (que ce soit le refactoring, l'optimisation, la correction de bugs, ...).

Malheureusement, dans ce cas, le test unitaire perd une partie de sa crédibilité: puisqu'il a été modifié, il ne confirme pas la fonction après le changement se comporte de la même manière qu'auparavant.

Par exemple, imaginons que quelqu'un ajoute un appel à oven.preheat()(optimisation!) Dans votre exemple de préparation de biscuits:

• Si vous moquez l'objet du four, il n'attendra pas cet appel et échouera au test, bien que le comportement observable de la méthode n'ait pas changé (vous disposez toujours d'un pan de cookies, espérons-le).
• Un talon peut échouer ou non, selon que vous avez uniquement ajouté les méthodes à tester ou l'interface entière avec certaines méthodes factices.
• Un faux ne devrait pas échouer, car il devrait implémenter la méthode (en fonction de l'interface)

Dans mes tests unitaires, j'essaie d'être aussi général que possible: si la mise en œuvre change, mais que le comportement visible (du point de vue de l'appelant) est toujours le même, mes tests doivent réussir. Idéalement, le seul cas où je devrais modifier un test unitaire existant devrait être une correction de bogue (du test, pas de la fonction testée).

La valeur principale d'un tel test est qu'il rend votre implémentation refactorable.

J'avais l'habitude de faire beaucoup d'optimisations de performances au cours de ma carrière et j'ai souvent trouvé des problèmes avec le modèle exact que vous avez démontré: pour enregistrer N entités dans la base de données, effectuez N insertions. Il est généralement plus efficace de faire une insertion en masse en utilisant une seule instruction.

D'autre part, nous ne voulons pas non plus optimiser prématurément. Si vous ne sauvegardez généralement que 1 à 3 personnes à la fois, l'écriture d'un lot optimisé risque d'être excessive.

Avec un test unitaire approprié, vous pouvez l'écrire de la manière dont vous l'avez implémenté ci-dessus. Si vous pensez que vous devez l'optimiser, vous êtes libre de le faire avec le filet de sécurité d'un test automatisé pour détecter les erreurs éventuelles. Naturellement, cela varie en fonction de la qualité des tests, testez donc généreusement et testez bien.

L’avantage secondaire du test unitaire de ce comportement est de servir de documentation pour en déterminer le but. Cet exemple trivial peut sembler évident, mais étant donné le point suivant, il pourrait être très important.

Le troisième avantage, souligné par d’autres, est que vous pouvez tester des détails sous la couverture qui sont très difficiles à tester avec des tests d’intégration ou de réception. Par exemple, si tous les utilisateurs doivent être enregistrés de manière atomique, vous pouvez écrire un scénario de test pour cela, ce qui vous permet de savoir qu'il se comporte comme prévu et sert également de documentation pour une exigence qui peut ne pas sembler évidente. aux nouveaux développeurs.

Je vais ajouter une pensée qui m'a été donné par un instructeur TDD. Ne testez pas la méthode. Testez le comportement. En d'autres termes, vous ne testez pas que cela savePeoplefonctionne, vous testez que plusieurs utilisateurs peuvent être enregistrés en un seul appel.

J'ai constaté que ma capacité à effectuer des tests unitaires de qualité et des TDD s’améliorait lorsque j’avais cessé de penser aux tests unitaires comme à la vérification du fonctionnement d’un programme, mais plutôt qu’ils vérifiaient qu’une unité de code répondait à mes attentes . Ce sont différents. Ils ne vérifient pas que cela fonctionne, mais ils vérifient que cela fait ce que je pense qu'il fait. Quand j'ai commencé à penser de cette façon, ma perspective a changé.

Devrait bakeCookies()être testé? Oui.

Comment une fonction comme celle-ci devrait-elle être testée par unité, en supposant que cela soit le cas? Il m'est difficile d'imaginer un type de test unitaire qui ne se contente pas de simuler la pâte, la casserole et le four, puis d'affirmer que des méthodes sont utilisées.

Pas vraiment. Examinez attentivement CE QUE la fonction est censée faire - elle est censée définir l' ovenobjet dans un état spécifique. En regardant le code, il apparaît que les états des objets panand doughimportent peu. Donc, vous devriez passer un ovenobjet (ou vous en moquer) et affirmer qu'il se trouve dans un état particulier à la fin de l'appel de la fonction.

En d'autres termes, vous devriez affirmer que bakeCookies()cuit les cookies .

Pour des fonctions très courtes, les tests unitaires peuvent sembler être un peu plus que de la tautologie. Mais n'oubliez pas que votre programme durera beaucoup plus longtemps que le temps que vous employez pour l'écrire. Cette fonction peut ou non changer dans le futur.

Les tests unitaires remplissent deux fonctions:

1. Il teste que tout fonctionne. C’est la fonction la moins utile des tests unitaires et il semble que vous semblez ne considérer cette fonctionnalité que lorsque vous posez la question.

2. Il vérifie que les futures modifications du programme ne suppriment pas les fonctionnalités précédemment implémentées. C'est la fonction la plus utile des tests unitaires et elle empêche l'introduction de bogues dans les gros programmes. C'est utile dans le codage normal lors de l'ajout de fonctionnalités au programme, mais plus utile dans le refactoring et les optimisations où les algorithmes centraux mettant en œuvre le programme sont modifiés de manière spectaculaire sans changer aucun comportement observable du programme.

Ne testez pas le code dans la fonction. Au lieu de cela, vérifiez que la fonction fait ce qu'elle dit. Lorsque vous examinez les tests unitaires de cette manière (fonctions de test, pas de code), vous réalisez que vous ne testez jamais les constructions de langage ni même la logique d'application. Vous testez une API.

SavePeople () doit-il être testé par unité, ou de tels tests équivaudraient-ils à tester la construction de langage forEach intégrée?

Oui. Mais vous pourriez le faire d'une manière qui revérifierait la construction.

La chose à noter ici est comment cette fonction se comporte quand un savePersonéchec à mi-parcours? Comment est-ce censé fonctionner?

C’est le genre de comportement subtil que la fonction fournit que vous devez appliquer avec les tests unitaires.

La clé ici est votre point de vue sur une fonction particulière aussi triviale. La plupart de la programmation est triviale: attribuez une valeur, faites des calculs, prenez une décision: si cela vous suffit, continuez une boucle jusqu'à ... Isolément, tout est trivial. Vous venez de terminer les 5 premiers chapitres de tout livre enseignant un langage de programmation.

Le fait qu’il soit si facile de passer un test devrait être un signe que votre conception n’est pas si mauvaise. Préféreriez-vous un design difficile à tester?

"Cela ne changera jamais." Voici comment la plupart des projets échoués commencent. Un test d'unité détermine uniquement si l'unité fonctionne comme prévu dans certaines circonstances. Faites-le passer et vous pourrez alors oublier ses détails d'implémentation et simplement l'utiliser. Utilisez cet espace cérébral pour la tâche suivante.

Savoir que les choses fonctionnent comme prévu est très important et n’est pas anodin dans les grands projets et en particulier dans les grandes équipes. S'il y a une chose en commun entre les programmeurs, c'est que nous avons tous eu à faire face au code terrible de quelqu'un d'autre. Le moins que nous puissions faire est de passer des tests. En cas de doute, écrivez un test et passez à autre chose.

SavePeople () doit-il être testé par unité, ou de tels tests équivaudraient-ils à tester la construction de langage forEach intégrée?

@BryanOakley a déjà répondu à cette question, mais j'ai quelques arguments supplémentaires (je suppose):

Tout d'abord, un test unitaire sert à vérifier l'exécution d'un contrat et non la mise en œuvre d'une API. le test doit définir les conditions préalables, puis appeler, puis vérifier les effets, les effets secondaires, les invariants et les conditions de publication. Lorsque vous décidez quoi tester, l'implémentation de l'API n'a pas d'importance (et ne devrait pas l'être) .

Deuxièmement, votre test sera là pour vérifier les invariants lorsque la fonction changera . Le fait que cela ne change pas maintenant ne signifie pas que vous ne devriez pas avoir le test.

Troisièmement, il est utile d’avoir mis en œuvre un test trivial, à la fois dans une approche TDD (qui le prescrit) et en dehors de celle-ci.

Lors de l'écriture en C ++, pour mes classes, j'ai tendance à écrire un test trivial qui instancie un objet et vérifie les invariants (assignable, régulier, etc.). J'ai trouvé surprenant combien de fois ce test est rompu au cours du développement (en ajoutant, par exemple, un membre non amovible dans une classe, par erreur).

Je pense que votre question se résume à:

Comment est-ce que je teste une fonction vide sans que ce soit un test d'intégration?

Si nous modifions votre fonction de cuisson des cookies pour renvoyer des cookies, par exemple, le test devient immédiatement évident.

Si nous devons appeler pan.GetCookies après avoir appelé la fonction, nous pouvons toutefois nous demander si c'est vraiment un test d'intégration ou si nous ne testons que l'objet pan?

Je pense que vous avez raison de dire que les tests unitaires avec tout simulé et la vérification des fonctions xy et z étaient appelées valeur insuffisante.

Mais! Je dirais que dans ce cas, vous devriez refactoriser vos fonctions void pour renvoyer un résultat testable OU utiliser des objets réels et faire un test d'intégration

--- Mise à jour pour l'exemple createNewUser

• un nouvel enregistrement d'utilisateur doit être créé dans la base de données
• un email de bienvenue doit être envoyé
• l'adresse IP de l'utilisateur doit être enregistrée à des fins de fraude.

OK, cette fois le résultat de la fonction n'est pas facilement renvoyé. Nous voulons changer l'état des paramètres.

C'est là que je suis un peu controversé. Je crée des implémentations concrètes pour les paramètres stateful

S'il vous plaît, chers lecteurs, essayez de contrôler votre colère!

alors...

var validatedUserData = new UserData(); //we can use the real object for this
var emailService = new MockEmailService(); //a simple mock which saves sentEmails to a List<string>
var dataStore = new MockDataStore(); //a simple mock which saves ips to a List<string>

//run the test
target.createNewUser(validatedUserData, emailService, dataStore);

//check the results
Assert.AreEqual(1, emailService.EmailsSent.Count());
Assert.AreEqual(1, dataStore.IpsRecorded.Count());
Assert.AreEqual(1, dataStore.UsersSaved.Count());

Cela sépare les détails de mise en œuvre de la méthode testée du comportement souhaité. Une autre implémentation:

function createNewUser(validatedUserData, emailService, dataStore) {
  userId = dataStore.bulkInsedrtUserRecords(new [] {validateduserData});
  emailService.addEmailToQueue(validatedUserData);
  emailService.ProcessQueue();
  dataStore.recordIpAddress(userId, validatedUserData.ip);
}

Va toujours passer le test unitaire. De plus, vous avez l’avantage de pouvoir réutiliser les objets fictifs d’un test à l’autre, mais aussi de les injecter dans votre application pour les tests d’interface utilisateur ou d’intégration.

Vous devriez également tester bakeCookies- ce qui e / g devrait / devrait bakeCookies(egg, pan, oven)donner? Un œuf sur le plat ou une exception? À eux seuls, ils panne ovense soucient pas des ingrédients eux-mêmes, puisqu’aucun d’entre eux n’est censé le faire, mais bakeCookiesdevrait normalement donner des biscuits. De manière plus générale , il peut dépendre de la façon dont doughest obtenue et s'il est une chance qu'il devienne simple eggou par exemple au waterlieu.