Une visite guidée des composants JavaScript : tester les composants

Dans ce numéro, le sujet que nous allons aborder est le test JavaScript pour vérifier si l'état et le mode de fonctionnement des composants sont comme prévu. Nous présenterons également une méthode de test qui permet d'écrire facilement des cas de test. Les tests mentionnés ici utilisent bien sûr des méthodes de test automatisées, ce qui constitue un élément important de l'assurance qualité (AQ) des logiciels. En ce qui concerne la Smart Queue présentée dans cette série d'articles, nos objectifs de test incluent :

• Création d'objets Task : La deuxième phase du code propose diverses méthodes de création, et il est nécessaire de tester l'état de l'objet après création.
• Ordre d'exécution des tâches dans la file d'attente : nous proposons deux façons de modifier l'ordre d'exécution : la configuration des priorités et des dépendances. Nous devons également tester l'impact des différentes configurations sur l'ordre.

Pour le premier objectif, vérifiez simplement que les propriétés de l'objet après création sont telles que attendues. Nous avons évoqué à plusieurs reprises « se conformer aux attentes », et Assert est conçu pour cela. En termes simples, l'assertion consiste à garantir que l'expression testée donne « vrai », sinon il faut en informer le testeur d'une manière ou d'une autre et l'aider à localiser le scénario de test où l'assertion a échoué.

Le deuxième objectif est un peu plus compliqué. Puisque nous cachons la file d'attente triée (_sorted) dans la fermeture lors du codage et de l'implémentation des composants, elle est inaccessible de l'extérieur. Il existe deux méthodes à considérer : (1) Refactoriser le code pour augmenter la testabilité du code. Il existe également deux méthodes de refactorisation : (a) Définir le commutateur de débogage et exposer _sorted à l'extérieur lorsqu'il est activé ; Ajoutez des fichiers d'indépendance, en épissant le code de manière build pour enfin générer une version de test. (2) Testez les résultats du comportement plutôt que du processus. La première méthode approfondit essentiellement l'état d'exécution du composant, tandis que cette méthode vérifie uniquement les résultats d'exécution du composant. Ce numéro utilise cette dernière méthode de test, et la première méthode de test est laissée aux lecteurs intéressés pour qu'ils puissent s'entraîner :)

Il convient de noter que personnellement je ne suis pas d'accord avec la première méthode a. Pourquoi ? Permettez-moi d'abord de parler du concept de conception de cette file d'attente de tâches :

• Il s'agit simplement d'une file d'attente qui se charge uniquement d'ajuster l'ordre d'exécution des tâches « à la demande » et ne prête pas attention aux détails individuels des tâches. En d’autres termes, il opère sur la tâche globale sans se soucier du comportement et des performances spécifiques à la tâche.
• Il s'agit d'une file d'attente sécurisée. Les utilisateurs (les « clients » mentionnés dans le premier numéro) peuvent y ajouter des tâches sans craindre que les informations sur les tâches soient vues par d'autres clients. Il convient de noter que la deuxième phase du code d'implémentation contient SmartQueue.Queue = [[], [], []]. Par conséquent, les éléments de la file d'attente sont accessibles en externe. Le code est uniquement destiné à des fins d'introduction, vous pouvez supprimer en toute sécurité SmartQueue.Queue = pour obtenir un contrôle de sécurité.

Source : Alipay UED