8
votes

Test des fonctions JavaScript à l'intérieur des fonctions anonymes

est-il possible de tester myinnerfunction ci-dessous? xxx

car myInnerfunction est essentiellement un membre privé de la fonction extérieure exécutée anonymement exécutée, Il ne semble pas que cela soit testable de l'extérieur.


2 commentaires

Les réponses apportent une question plus large maintenant. C'était un exemple trivial. J'ai des fonctions JS qui sont étroitement liées à une structure de Dom attendue qu'ils lui sont couplées et ne peuvent être tirées d'une API générique des services publics publics. J'ai besoin de tester ces fonctions; Leur logique est significative, mais elles sont toutes déclarées sur DOM - prêtes à l'emploi dans une fonction littérale et rattachées comme des gestionnaires d'événements aux éléments DOM. Ils sont essentiellement privés et étroitement associés à la structure DOM, mais je dois toujours les tester. Où devraient-ils résider pour que je puisse y avoir accès à mes tests?


Afin de prendre les méthodes, je souhaite tester la fonction anonyme qui est exécutée sur-DOM - prêt à l'emploi de la bibliothèque, je les ai dépassé dans un "package" qui correspond à la fonctionnalité suivante dans ma page. Bien que ce code ne soit réellement utilisé que sur cette page particulière et uniquement via les gestionnaires d'événements, j'ai ajouté à cette DOM spécifique, au moins je peux tester cette logique maintenant. Merci à tous de vous diriger. Toutes les autres pensées sont les bienvenues.


4 Réponses :


1
votes

Le test unitaire AFAIK ne concerne pas le fonctionnement interne des choses que vous testez. Le point est que vous testez la fonctionnalité, c'est-à-dire: il fait ce que c'est censé faire, pas comment il le fait. Donc, s'il utilise un membre privé interne, il doit ne doit pas être testable ...


0 commentaires

1
votes

Vous pouvez tester le comportement externe observable. Dans ce cas simple, vous avez retourné juste la valeur de la fonction interne, mais dans un exemple de monde réel, vous pouvez combiner le résultat de cette fonction intérieure avec autre chose. Cette combinaison est ce que vous testez, pas les sorties directes de la méthode privée.

essayer de tester la méthode privée rendra votre code difficile à changer et à refacteur, même lorsque le comportement externe est préservé. Cela dit, j'aime visualiser des tests d'unité non pas aussi importants de votre code, mais simplement fournir un exemple de l'API et la manière dont il se comporte dans des conditions différentes. ;)


0 commentaires

6
votes

Vous pouvez exposer intentionnellement un crochet de test au monde extérieur, comme éventuellement ceci: xxx

maintenant, une fois que VAL a été exécuté au moins une fois, vous pouvez référencer val .__ test_inner et l'appelez avec des entrées testables.

Les avantages de cette approche: 1. Vous choisissez ce qui est exposé et non (aussi une cause négative »que vous devez vous rappeler de le faire) 2. Tout ce que vous obtenez est une référence de copie à la méthode privée, vous ne pouvez donc pas le changer accidentellement, n'utilisez-le que et voyez ce qu'il produit

Les inconvénients: 1. Si le membre privé change (ou s'appuie sur) état de sa fonction hôte / parent, il est plus difficile pour vous de tester un appareil sur cela, car vous devez recréer ou contrôler artificiellement l'état hôte / parent en même temps. 2. Comme mentionné, ces crochets doivent être ajoutés manuellement

Si vous avez été vraiment intelligent, vous pourriez avoir votre processus de construction rechercher des blocs de commentaires tels que ci-dessus et supprimer les crochets de test lors de la création de votre construction de production.


2 commentaires

J'aime votre approche, même si je veux essayer de garder le code de production aussi propre que possible. Ce que je fais vraiment, c'est une fonction à un gestionnaire d'événements Dom-Ready de la bibliothèque, donc je ne sais pas si je pouvais le faire et que je lui ai toujours accès à la bibliothèque.


C'est exactement pourquoi j'ai suggéré les blocs de bande de construction de processus de processus de commentaires formatés comme ceux ci-dessus.



1
votes

Je pense que ma réponse est (comme tant de choses) que je le fais mal. Ce que j'ai défini comme une fonction «privée» est vraiment quelque chose qui doit être testé. Ce n'était que privé parce que je ne voulais pas l'exposer dans une API d'utilitaires ou quelque chose comme ça. Mais cela pourrait toujours être exposé grâce à mon espace de noms d'application.

Donc, dans la fonction anonyme exécutée sur-DOM - prête à l'emploi, je joins mes fonctions prédéfinies en tant que gestionnaires d'événements aux hameçons DOM appropriés. Les fonctions elles-mêmes, bien que non stockées avec mes fonctions d'utilitaires plus ouvertes, sont toujours stockées publiquement dans un emballage de mon espace de noms associé à la structure DOM qu'ils concernent. De cette façon, je peux les obtenir et les tester de manière appropriée.


0 commentaires