Rubyのテストによるコードカバレッジの分析

まず、3つのクラスの小さなテストプロジェクトを作成し、 SimpleCov gemを使用してカバレッジを分析します。最後に、カバレッジ分析がプロジェクトにどのように役立つか、Rubyのカバレッジの欠点は何かについて少し考えます。













実験プロジェクト



テストのためのプロジェクトとして、母親と父親に散歩をする許可を求める可能性のある少年についての小さな物語が撮影されました。







#      ,     , #     .       ,   #     ,      . class Mother def permit_walk?(child) child.scarf_put_on && child.homework_done end end
      
      





 #     ,    ,       . class Father def permit_walk?(child) child.scarf_put_on end end
      
      





 #     ,     , #   .      ,   . #  , ,      . class Child attr_reader :homework_done, :scarf_put_on def initialize(mother, father) @mother = mother @father = father @homework_done = false @scarf_put_on = false end def do_homework! @homework_done = true end def put_on_scarf! @scarf_put_on = true end def walk_permitted?(whom_to_ask) parent = if whom_to_ask == :mother @mother else @father end parent.permit_walk?(self) end end
      
      





テストでカバーし、カバレッジを監視します



テストは意図的にすべてのシナリオをカバーしているわけではありません。







 require "simplecov" SimpleCov.start require "rspec" require_relative "../lib/mother" require_relative "../lib/father" require_relative "../lib/child" RSpec.describe Child do let(:child) { Child.new(Mother.new, Father.new) } context "when asking mother without scarf and without homework" do it "isn't permitted to walk" do expect( child.walk_permitted?(:mother) ).to be false end end context "when asking mother with scarf and with homework" do it "is permitted to walk" do child.put_on_scarf! child.do_homework! expect( child.walk_permitted?(:mother) ).to be true end end end
      
      





SimpleCovは、実際にはRuby 1.9.3+の世界でのカバレッジ分析の独占者です。 これは、標準ライブラリのカバレッジモジュールの便利なラッパーです。







テストファイルの先頭で接続が2行に減ります。プロジェクトファイルを接続する前にSimpleCovの初期化を実行することが重要です。 テストを実行します。







 rspec
      
      





ほら! レポートカバレッジ/ index.htmlが生成されました。 リンクでそれを見ることができますが、ここでは遠くに行かないようにスクリーンショットをいくつか残します(一般的なレポートはヘッダー画像として使用されます)。









father.rb









child.rbからの抜粋







分析カバレッジのボーナス



父親が許可を求める方法がテストされていないことは、レポートからすぐに明らかになります。 したがって、カバレッジ分析の明らかな利点: TDDがない場合レポートは何かをテストするのを忘れたことを示すことができます。 プロジェクトがレガシーであり、テストの難しい方法が始まったばかりである場合、レポートは、どこに最善の努力を向けるべきかを決めるのに役立ちます。







2番目に考えられる用途は、コミットの品質を自動的に保証することです。 CIサーバーは、合計カバレッジの減少につながるコミットを拒否でき、テストされていないコードがリポジトリに表示される可能性を大幅に減らします。







そのカバレッジ分析は



第一に、100%のカバレッジはバグの不在を保証するものではありません。 簡単な例:このようにMotherクラスを変更した場合:







 class Mother def permit_walk?(child) # child.scarf_put_on && child.homework_done child.homework_done end end
      
      





クラスカバレッジは100%のままで、テストは緑色のままですが、ロジックは明らかに間違っています。 ミュータントgemを使用して、「欠落しているが必要な」テストを自動的に検出できます。 私はまだ実際に試していませんが、Readmeとgithubの星の数から判断すると、このライブラリは本当に便利です。 しかし、これは別の投稿のトピックであり、どういうわけかそれを取得します。







第二に、Rubyでは、行ごとのカバレッジ分析のみが可能であり、分岐カバレッジと条件カバレッジはサポートされていません。 単線タイプでは







 some_condition ? 1 : 2 some_condition || another_condition return 1 if some_condition
      
      





分岐点はありますが、実行の可能な分岐が1つだけテストに合格した場合でも、カバレッジは100%を示します。 このトピックに関するRubyのプルリクエストがありましたが、2年前からメンテナーから何も聞いていません 。 なんて残念。







あとがき



私はコードを書いた直後にテストを書くことを好み、カバレッジはまだテストされていないメソッドのリマインダーとして機能します(例外ハンドラーをテストすることをしばしば忘れます)。 一般に、カバレッジ分析はいくつかの利点をもたらす可能性がありますが、100%のカバレッジは必ずしもテストが十分であることを意味しません。







この記事で使用されている資料:










All Articles