テストが他の開発者によって削除されていないことを確認するにはどうすればよいですか?


8

仕事中に興味深い協調コーディングの問題に遭遇しました。

私はいくつかのユニット/機能/統合テストを書き、アプリケーションに新しい機能を実装しました。これにより、最大20人の開発者が作業します。すべてのテストに合格し、コードをチェックインしました。翌日、プロジェクトを更新したところ、(偶然に)テストメソッドの一部が他の開発者によって削除されていることに気付きました(開発者側で問題をマージしています)。新しいアプリケーションコードは変更されませんでした。

このような問題を自動的に検出するにはどうすればよいですか?つまり、コードが引き続き機能する(または削除されなかった)ことを自動的にチェックするテストを作成します。テストに対して同じようにするにはどうすればよいですか?

必要に応じて、Java、JUnit、Selenium、SVN、Hudson CIを使用しています。


1
実際に適切なプル->マージ->コミットを実行している場合に、コードのスワス全体を「誤って」削除する方法すらわかりません。
アノン。

@Anonはどちらかと思いますが、彼は急いでいてコードをすばやくコミットする必要があったため、物事のマージや中身にあまり注意を払わなかったと言います。:-/とにかく、私はまだそのような問題をCIレベルで自動的に検出したいと思っています。
parxier

10
そして、「急いでいた」人はマネージャーからの静かな話を必要とするかもしれません、そのような振る舞いは怠惰であり、受け入れられないはずです。
quick_now

1
これが可能になるのは、非常に長い時間をかけて変更された多数のファイルを含む大きな変更をチェックインしている場合に限られます。通常、コードが「失われる」可能性さえあるような巨大なマージはすべきではありません...それは私にとって問題の本当の原因のように聞こえます。
ディーンハーディング

1
これが、個々の開発者が中央集中型VCSのトランクにマージすることを許可されるべきではない理由です。怠惰な開発者は、他の人のものを壊滅させる傾向があります(自分自身で有罪となります)。
Chris K

回答:


4

私はHudson for CIに精通していませんが、私のCIツールはコードカバレッジを計算することもできます。コードカバレッジがダウンしたときに通知するプロセスを記述できる場合、それはテストが削除されたことを示す良い指標になります。また、テストなしで新しいコードが追加されたかどうかもわかります。あなたが尋ねていたものではありませんが、知ってよかったです。


3
Timの回答に関するコメントで、まさにこの点について述べようとしていました。コードカバレッジパーセンテージは決して低下してはなりません。
フランクシェアー

メトリックの良い角度!

あれはどんな道具なの?
Chris K

@Chrisでは、各ビルドのコードカバレッジを計算するように構成したTFS + TeamBuildを使用します。
Marcie、

とにかく現時点ではテストカバレッジが非常に低いため、この特定のプロジェクトでは機能しません。そのため、Timのアイデアを試さなければなりません。しかし、あなたは私に良い解決策を与えてくれました、そしてそれは私の質問に対する最良の答えだと思います。
parxier

12

標準の免責事項が適用されます。私たちは社会問題のエンジニアリングソリューションを作成しています。ただし、これはプロジェクトの衛生上の問題であるため、トイレは社会問題のエンジニアリングソリューションであると言うのと少し似ています。

HudsonからのRSSフィードを仕事に渡してもらいます。Hudsonレポートでテストの数を数えます。それが減少する場合は、アラームを鳴らします。アラームが鳴ったときに自動ダフェを持っています。

コミットの責任を識別し、罰することができます。あなたの問題はなくなります。

このソリューションの結果として、他の問題が発生する可能性があります。めまいが持続する場合は、医師にご相談ください。


1
+1:「私たちは社会問題のエンジニアリングソリューションを作成しています」これで答えは終わりです。残りの答えは、その1つのステートメントよりも価値が低くなります。
S.Lott、2011

2
@SLottはい。でも、正しいことを簡単に行えるようにすれば、それは完了です。私たちはチーム全体への自動メールを使用しましたが、それはビルドを壊すことによって引き起こされました。できます; あなたはより慎重になります。私は個人的に、この社会問題を解決しようとすることの有用性を疑っています。正直言って、テストを削除しても問題ない場合は、企業文化は品質に反しています。
ティムウィリスクロフト、

わあ、私はポルトガル人です。オートダフェとは何なのかまったくわかりませんでした。
R.マルティーニョフェルナンデス

テスト数は正当な理由で減少する可能性があります:リファクタリングはクラスとそのすべてのユニットテストを削除する可能性があります。ただし、テスト数が減少した理由を見つけることは依然として価値があります。
フランク・シーラー

@フランク有効な理由でテスト数が無効なものと比較してどれくらいの頻度で減少した場合、何が問題になると思います。それがほとんど正当な理由である場合、アラームは少し後に無視され、価値がなくなります。それがほとんど無効なものであるなら、それは良いかもしれません。これはどのくらいの頻度で発生しますか?そして実際には、@ parxier、それがあなたの知っていることが一度だけ起こった場合、過剰反応しているのではないでしょうか?
ジェームズ

2

組織的アプローチ

テストの削除者がテスト作成者と話すためにテストを削除することを要求するポリシーを設定します。通常、テストを削除するのは、テスト中の一部の機能を減価させた場合のみであり、それが頻繁に発生することはありません。

技術的アプローチ

これはより制御フリークなアプローチですが、チェックしたいすべてのテストの存在についてソースコードをスキャンする個別のテストを使用できます。おそらく、Hudsonとインターフェースして実行されたテストのリストを取得することもできます。


マージ中にスタッフが削除されました。偶然かもしれないし、怠惰かもしれません。政策は、誰もが無視するであろう経営からの「あなたはなすべき」を除けば、それほど多くのことをするつもりはない。しかし、公共の書き込みやむち打ちは、いくつかの注意を引くかもしれません。/ sarcoff
quickly_now

2
@quickly_now:「マージ中にスタッフが削除されました」。それは発砲の犯罪になるはずです。この振る舞いを許可する組織は、本当に多くの人々を削除し、悪の代わりに賢明なことをするために努力する人々に置き換える必要があります。
S.Lott、2011

事故-あなたはそれを初めて許すことができます。怠惰または悪意のある-はい-犯罪を解任します。
2011

個別のテストクラスを最新の状態に保つのは困難ですが、興味深いアイデアです。
parxier '

0

アートの答えに似ています。

コメントコメント を上手に使うことから始めます。各メソッドについて。予想される入力と出力、より複雑な関数の簡単な説明と名前を配置することを忘れないでください。

ガイドライン しかし、これは本当に開発者間のコミュニケーションの必要性があることを強調しています。チーム。一緒に作業するためのガイドラインが整っている必要があります...または少なくともプロジェクト担当者に相談してください マネージャーと彼にチームの間でこれを明確にするように頼みます。

適切なSVNの使用 方法クラスとメソッドを書き留めて追跡することもできます。また、SVNを使用しているときは、これらの削除が変更として追跡され、個別に記録され、良好な理由があることを心から願っています。

特別なプログラムを書くのではなく、diffを比較することもできます。メソッドの変更を追跡するためのSVNのファイル。


0

同じことが実際のコードでも発生する可能性があり、変更が存在しないことに気付くまではわかりません。

そうは言っても、手動でコード/機能などを削除することは非常に多いため、削除されたコードを悪いものとして特定することは困難であり、そのため、テストの数が他の誰かと同様に減少する可能性があります。


コードが削除されると、テストが中断します。テストが削除されても、何も壊れません。
parxier '
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.