テスト手法や複数人開発の詳しい人に質問です。

(CodeCompleteの内容は前提知識としてあるぐらい)

コードのマージ時にマージミスで重複行が発生してしまうのを防ぐ
良い方法ってご存じでしょうか。

具体的にはマージ時に、マージのミスで

call_method(foo)
if cond
call_method(foo)
end

みたいな重複行が発生することをチェックする仕組みがや取り組みが知りたいです。

なおテストケースではc1は網羅しててもメソッドの重複呼び出しだと場合によりテストが失敗しないので、テストをもっと書くべきというアドバイス以外でお願いします。

回答の条件
  • 1人10回まで
  • 13歳以上
  • 登録:2011/10/28 16:56:29
  • 終了:2011/11/02 09:13:26

ベストアンサー

id:cactusman No.1

さぼてん回答回数1ベストアンサー獲得回数12011/10/28 17:17:28

ポイント200pt

質問のようなことをやりたければ、Jenkinsを使ってる会社の人ということで回答しますが、静的解析ツールで重複しているコード数を把握し、増加を見るというのはどうでしょうか?

単なるマージで増加するのは普通はおかしいので、その都度チェックを入れればいい、という考えです。

そういうことをするのに、JavaだとPMDというツールが重複もチェックしてくれて、Jenkinsにはそれ用のPMD Pluginがあります。

Rubyには詳しくないですが、Flayというツールを使えば重複をチェックできるんじゃないんでしょうか?

残念ながらJenkinsにはPluginがないので、Plot Pluginなどを使えば増減を測定できるはずです。

id:secondlife

ありがとうございます、重複チェックのツール使うというのも機械的に把握できそうで良いですね~

2011/10/28 23:42:41

その他の回答(1件)

id:cactusman No.1

さぼてん回答回数1ベストアンサー獲得回数12011/10/28 17:17:28ここでベストアンサー

ポイント200pt

質問のようなことをやりたければ、Jenkinsを使ってる会社の人ということで回答しますが、静的解析ツールで重複しているコード数を把握し、増加を見るというのはどうでしょうか?

単なるマージで増加するのは普通はおかしいので、その都度チェックを入れればいい、という考えです。

そういうことをするのに、JavaだとPMDというツールが重複もチェックしてくれて、Jenkinsにはそれ用のPMD Pluginがあります。

Rubyには詳しくないですが、Flayというツールを使えば重複をチェックできるんじゃないんでしょうか?

残念ながらJenkinsにはPluginがないので、Plot Pluginなどを使えば増減を測定できるはずです。

id:secondlife

ありがとうございます、重複チェックのツール使うというのも機械的に把握できそうで良いですね~

2011/10/28 23:42:41
id:a-kuma3 No.2

a-kuma3回答回数4470ベストアンサー獲得回数18442011/10/28 20:41:50

ポイント100pt

質問に書いたケースは、単純化してるから余計にそう感じるのかもしれませんが、

この手のマージのミスを防ぐのはテストでは無い、と思います。


さすがに Git なり、バージョン管理システムを使っているだろうとは、想像しますが、

commit の単位が大きすぎるんじゃないでしょうか?

例えば、チケットの単位でしか commit を認めてない、とか。

Unit テストが通る、というのは大前提になると思いますが、その範囲内で、細かく commit していれば、

特定のコードを if でくくった程度のマージがミスるというのは、ちょっと想像がつきません。

id:secondlife

git 使っててますが、コミット単位は人それぞれです。(特に規約等では決めてません)

大量のコードをマージしまくるようなお仕事も中にはあって、その場合仕様の完全な把握は難しいので、どうしてもヒューマンエラーが発生してしまうこともあるので、そのことに対する具体的な手法があれば知りたいのです。

2011/10/28 23:44:52
id:a-kuma3

どうしてもヒューマンエラーが発生してしまう

なんとなく、想像はつきます。

障害分析とか、結構やるんですけど、「障害をテストで救う」というのが、そもそも間違っている、ということも往々にしてあります。


大量のコードをマージしまくるようなお仕事も中にはあって、

「だから、テストで救うしかない」ということを前提にしてしまってはいないですか?

具体的な場面が分かってないので、的を外しているかもしれませんが、

ヒューマンエラーを起こした原因は、がっつりコードを変更するような修正方法を

選択したことに問題があった、というケースには、よく遭遇します。

2011/10/29 00:15:15
  • id:garyo
    そもそもローカルでコンパイルが通ることを確認してこまめにコミットと更新してたら、マージミスなんてそう起こるとは思えないけど……。
  • id:a-kuma3
    redmine のノウハウを紹介してるページで、チケット番号をコミットのコメントに、みたいなのを良く見るんですよ。
    それを曲解して、チケットの単位=コミットの単位、としてるんじゃないかなあ、と。

    redmine は使ってませんけど、ぼくの身近にも、似たような事例はありますし。
  • id:ootadesi

  • id:sanemat
    本末転倒で違うとおもうけど書いとく

    Mockでonceとかtwiceとかstrictに書けば避けられるのかなあ
    可能だけどMockObjectの使い方として明らかに違う気もする
    http://xunitpatterns.com/Mock%20Object.html
  • id:secondlife
    x回呼ばれることを明示的に保証するテストを書きたいわけではないので、
    違うのですよねぇ。
    解答の一つでありますが、ある程度高レベルのAPIのメソッド呼び出しの呼び出し回数を記録しておき、マージ前と後で比較してチェックすることで人的コストは高いですが、意図しない変更は解りそうですね。



  • id:dann
    基本はレビューで防ぐしかないと思うんですが、レビューの補助情報として、高次のAPI呼び出しでtest coverageを取得して、coverageが低いところをレビューというのは、割とよくやってます。

    マージ用ブランチのCI結果のtest coverageをみて、それをベースにレビューするという感じです。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません