ステートメントがカバーされていない場合は、テスト カバレッジに移動します

php エディター Baicao が今日はカバレッジをテストする方法を紹介します。ソフトウェア開発プロセスでは、テスト カバレッジは重要な指標であり、テスト ケースごとのコード カバレッジの程度を評価するのに役立ちます。カバーされていないステートメントがあることが判明した場合は、何らかの手段でこの問題を解決できます。この記事では、カバレッジをテストする方法と、カバーされていないステートメントに対処する方法について説明します。

質問内容

setupConfig()というgo関数があり、それをテストするためのTest_setupconfigがあり、正常にテストされます。しかし、カバレッジをテストして HTML レポートを確認したところ、Viper パッケージから返されたいくつかのエラーの処理がカバーされていないことがわかりました。なぜこれがカバーされないのでしょうか?これはどう対処すればよいでしょうか?

解決策

カバレッジ レポートは、テスト中に実行されたコードの量を示します。表示されているのは、これらの return ブロック内の if ステートメントがテストされていないということです。これは、失敗してエラーを返すように設計された単体テストがないことを意味します。正しい入力が与えられたときにコードが機能することをテストする一方で、間違った入力が与えられたときにテストが正しく安全に失敗することを確認することも重要です。

ただし、これらのエラーは独自のパッケージにはなく、viper パッケージから発生するため、これは奇妙な状況です。この時点で、「実際に何をテストしているのか?」という質問を自問することが重要です。 viper パッケージを使用する場合、そのパッケージは徹底的にテストされていると想定され、viper のバグ用に独自のテストを作成しても、実際の改善はなく、それらのテストを 2 倍にするだけです。このため、これらのブランチのテストを省略することもあります。現実的には、viper パッケージが間違っている場合、すべての入力が静的で、示されているようにハードコードされていると仮定すると、コードには問題はありませんが、 viper ライブラリ。

本当に 100% のカバレッジを取得し、すべてのデシジョン ツリーをテストしたい場合、唯一の方法は、viper パッケージを何らかの抽象化の背後に置くことです。ほとんどの場合、これは関数に渡されるインターフェイスであり、実稼働環境でもテスト環境でも複数の実装が可能です。

そうは言っても、このように関数内のすべての値をハードコーディングすることはお勧めできません。理想的には、構成構造の値は、ローカル構成ファイル、環境変数、コマンド ライン フラグ、またはそれらの組み合わせから取得する必要があります。これにより、このセットアップ関数が設定を取得するためのインターフェイスを受け入れるようになり、テストでインターフェイスの実装をモックするだけで済むため、関数のテストが簡単になります。したがって、次のようになります:

config.go： リーリー

config_test.go： リーリー

これを実行し、

setupConfig() 関数の受け入れインターフェイスを提供することにより、運用環境で実行するときにその関数の実装を提供できるだけでなく、テストを実行するときにハードコードしてテスト データをシミュレートできることを意味します。それ。また、データベースなどの他のサービスと対話するときにもよく使用されます。テストの実行時にデータベースを起動して接続する代わりに、データベースと対話する方法を指示するインターフェイスをコードに受け入れさせ、テストでデータベースをシミュレートすることができます。これにより、コードの一部を分離し、必要な部分だけをテストできます。

以上がステートメントがカバーされていない場合は、テスト カバレッジに移動しますの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。