Maison  >  Article  >  développement back-end  >  Aller au test de couverture, si la déclaration n'est pas couverte

Aller au test de couverture, si la déclaration n'est pas couverte

WBOY
WBOYavant
2024-02-11 10:36:08981parcourir

Aller au test de couverture, si la déclaration nest pas couverte

l'éditeur php Baicao vous présente aujourd'hui une méthode de test de couverture. Dans le processus de développement logiciel, la couverture des tests est un indicateur important, qui peut nous aider à évaluer le degré de couverture du code par les cas de test. Et si nous constatons que certaines déclarations ne sont pas couvertes, nous pouvons résoudre ce problème par certains moyens. Dans cet article, nous explorerons comment tester la couverture et comment gérer les déclarations non couvertes.

Contenu de la question

J'ai une fonction go appelée setupConfig() et j'ai un Test_setupconfig pour la tester et elle teste bien. Mais lorsque je l'ai testé pour la couverture et examiné le rapport HTML, il a montré que ma gestion de certaines erreurs renvoyées par le package Viper n'était pas couverte. Pourquoi cela n'est-il pas couvert ? Comment dois-je gérer cela ?

Solution de contournement

Le rapport de couverture vous indique la quantité de code exécutée pendant le test. Ce que vous voyez, c'est que ces if 块中的 return instructions ne sont pas testées, ce qui signifie que vous n'avez aucun test unitaire conçu pour échouer et renvoyer une erreur. Tout en vérifiant que votre code fonctionne lorsqu'une entrée correcte est donnée, il est également important de s'assurer que les tests échouent correctement et en toute sécurité lorsqu'une entrée incorrecte est donnée.

Cependant, c'est une situation étrange car ces erreurs ne se trouvent pas dans votre propre package, ces erreurs proviennent de problèmes avec la bibliothèque viper 包。此时,重要的是要问自己一个问题“我真正测试的是什么?”。如果您使用 viper 包,那么假设该包经过了彻底的测试,并且通过为 viper 错误创建您自己的测试,您只是在这些测试上加倍,而没有真正的改进。出于这个原因,有时我们选择省略测试这些分支,因为实际上,如果 viper 包错误 - 并假设您的所有输入都是静态的并且像所示的那样进行硬编码 - 那么这不是您的代码的问题,而是 viper.

Si vous vraiment voulez obtenir une couverture à 100 % et tester tous les arbres de décision, le seul moyen est de mettre un viper package derrière une abstraction. Il s'agit très probablement d'une interface transmise à la fonction, permettant plusieurs implémentations, que vous soyez en production ou en test.

Cela dit, coder en dur toutes les valeurs dans une fonction comme celle-ci n'est pas recommandé. Idéalement, vous souhaitez que les valeurs de la structure de configuration proviennent de fichiers de configuration locaux, de variables d'environnement, d'indicateurs de ligne de commande ou d'une combinaison de ceux-ci. En faisant cela, vous faites en sorte que cette fonction de configuration accepte une interface pour récupérer la configuration, ce qui rend la fonction facile à tester puisque tout ce que vous avez à faire est de simuler l'implémentation de l'interface dans votre test. Cela ressemblera donc à ceci :

config.go

type ConfigController interface {
    GetInput() Config
}

func setupConfig(controller ConfigController) error {
    config := controller.GetInput()
    // your code here
}

config_test.go

type mockConfigController struct {}

func (m *mockConfigController) GetConfig() Config {
    return Config{
        // your config here
    }
}

func Test_setupConfig(t *testing.T) {
    configController := &mockConfigController{}
    err := setupConfig(configController)
    // rest of test here
}

En faisant cela et en fournissant une interface d'acceptation pour votre fonction setupConfig(), cela signifie que vous pouvez fournir une implémentation de fonction lors de l'exécution en production, mais également utiliser des données de test codées en dur pour les simuler lors de l'exécution de tests. Il est également souvent utilisé lors de l'interaction avec d'autres services, tels que des bases de données. Au lieu de devoir démarrer la base de données et de vous y connecter lorsque vous exécutez le test, vous pouvez demander à votre code d'accepter une interface qui lui indique comment interagir avec la base de données et la simuler dans vos tests. Cela vous permet d'isoler des parties de votre code et de tester uniquement ce que vous voulez.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

Déclaration:
Cet article est reproduit dans:. en cas de violation, veuillez contacter admin@php.cn Supprimer