(CodeCompleteの内容は前提知識としてあるぐらい)
コードのマージ時にマージミスで重複行が発生してしまうのを防ぐ
良い方法ってご存じでしょうか。
具体的にはマージ時に、マージのミスで
call_method(foo)
if cond
call_method(foo)
end
みたいな重複行が発生することをチェックする仕組みがや取り組みが知りたいです。
なおテストケースではc1は網羅しててもメソッドの重複呼び出しだと場合によりテストが失敗しないので、テストをもっと書くべきというアドバイス以外でお願いします。
質問のようなことをやりたければ、Jenkinsを使ってる会社の人ということで回答しますが、静的解析ツールで重複しているコード数を把握し、増加を見るというのはどうでしょうか?
単なるマージで増加するのは普通はおかしいので、その都度チェックを入れればいい、という考えです。
そういうことをするのに、JavaだとPMDというツールが重複もチェックしてくれて、Jenkinsにはそれ用のPMD Pluginがあります。
Rubyには詳しくないですが、Flayというツールを使えば重複をチェックできるんじゃないんでしょうか?
残念ながらJenkinsにはPluginがないので、Plot Pluginなどを使えば増減を測定できるはずです。
質問に書いたケースは、単純化してるから余計にそう感じるのかもしれませんが、
この手のマージのミスを防ぐのはテストでは無い、と思います。
さすがに Git なり、バージョン管理システムを使っているだろうとは、想像しますが、
commit の単位が大きすぎるんじゃないでしょうか?
例えば、チケットの単位でしか commit を認めてない、とか。
Unit テストが通る、というのは大前提になると思いますが、その範囲内で、細かく commit していれば、
特定のコードを if でくくった程度のマージがミスるというのは、ちょっと想像がつきません。
それを曲解して、チケットの単位=コミットの単位、としてるんじゃないかなあ、と。
redmine は使ってませんけど、ぼくの身近にも、似たような事例はありますし。
Mockでonceとかtwiceとかstrictに書けば避けられるのかなあ
可能だけどMockObjectの使い方として明らかに違う気もする
http://xunitpatterns.com/Mock%20Object.html
違うのですよねぇ。
解答の一つでありますが、ある程度高レベルのAPIのメソッド呼び出しの呼び出し回数を記録しておき、マージ前と後で比較してチェックすることで人的コストは高いですが、意図しない変更は解りそうですね。
マージ用ブランチのCI結果のtest coverageをみて、それをベースにレビューするという感じです。