チームがユニットテストを自動的に実行したくないのはなぜですか？
私は.netでチームを管理しています。彼らはユニットテストを書いていて、定期的にローカルで使用していて、大好きです。しかし、彼らは単体テストを個別のプロジェクトとして保持することを強く求め続けており、週に1回程度、それらを共同ビルドサーバーで実行したいと考えています。
対照的に、JSチームは、プルリクエストごとにビルドサーバーでテストを実行しています。
私は彼らにテストをコードの近くに置くことの利点を説明しようとし、頻繁にテストを実行しますが、ビルドが遅すぎる、またはテストが緊急ビルドを妨げると何が起こるのかという恐れを持ち続けます。
それは私の心を揺さぶっていて、何か足りないものがあるのではないかと思っています。
この種の反発の理由として考えられるものは何ですか？彼らはテストを書いて喜んでおり、「私たちが決断するまで」メインブランチにマージすることを拒否するブランチですでに100近くのテストが書かれていると言っています。 （つまり、メインコードから遠く離れた独立したプロジェクトでテストを維持しても問題ないことを伝えます。）
チームはすぐに単体テストの作成を採用しました。彼らはそれらを有用であると感じ、さらにテストを続けています。私は今、CIでテストを実行してもらいたいと思っています。そのため、抵抗を感じています。
まず、ここで@ -Gnatに感謝します 実際の洞察を見つける ここで問題を解決し、実際の問題に到達するために知っておくべきことを教えてください。
追加したテストコードがビルドにコンパイルされないように、単体テストと統合テストを独自のプロジェクトに分離することに同意しました。
また、コードを小さなリポジトリに分離して、各ビルドに15〜30分かかることがなくなるまで、非ブロッキングワークフローでテストを実行します。
そして今のところ、すべてのプルリクエスト（PR）でプロジェクトをビルドするのではなく、毎晩のビルドでテストを実行することに同意しています。これはテストが物事を遅くすることによって彼らが本当に意味したものです...彼らは実際にすべてのPRでビルドを行うことを意味しました。彼らは1日に数十回PRを行います。緊急ビルドをブロックするテストに関する彼らの主な懸念は、誰もが一度にコードをマージしようとしていて、最後にテストを実行できるようにしたいときに、緊急ビルドがしばしば数十のPRになってしまうという懸念でした。そのプロセスの、そして途中のすべてのポイントで個別のビルドを必要としない。
必要なすべての情報を提供する単一の回答はなく、最良の回答のほとんどはコメントで提供されたので、この回答を作成して、最も意味のあるすべてのものを要約しました。
欠けていた重要な情報は次のとおりです。
- テストがテスト中のコードに近すぎる場合は、テストファイルを.dllにビルドしないように.netに指示するのに非常に時間がかかり、それらを個別のプロジェクトとして保持する方がはるかに簡単です。
- 実際の問題は、テストを実行するために必要なビルドでした。彼らが実行したくないテストではなく、ビルドでした。彼らは、彼らがそうであるほど頻繁にコードをマージすることができないようにするためにビルドが欲しくなかった。ローカルでは、自分のコンピューターでデバッグビルドを実行してテストを1分以内に実行できますが、CIサーバーでははるかに時間がかかります。
私は.netでチームを管理しています。
関係ありません。
彼らはユニットテストを書いています...そして、週に1回程度それらを実行したいだけです。
ユニットテスト は週に1回実行されません。あなたはそれらを通過させることができるあなたができる最も少ない量のコードを書く前後にそれらを実行します。テストは通常は良いですが、これらがユニットテストではないものは何でも。
そしてそれを愛する。
良い。
ただし、ユニットテストを個別のプロジェクトとして保持するように要求し続けます。
関係ありません。
私たちのjsチームはすべてのコミットでテストを実行しています。
それで全部です？非常に頻繁にコミットするか、あまりテストしません。最初にローカルでテストします。
このストーリーから取り残されているのは、テストをリファクタリングする頻度です。これらのテストは、変更するために非常に大きな努力を払っている一部の固定された保護者ですか？リファクタリングテストは、リファクタリングコードと同じくらい簡単かつ頻繁に行う必要があります。
私は彼らにテストをコードの近くに置くことの利点を説明しようとし、頻繁にテストを実行しますが、ビルドが遅すぎる、またはテストが緊急ビルドを妨げると何が起こるのかという恐れを持ち続けます。
彼らは彼らが働くことができるところならどこにでもテストを置くことを許されるべきです。また、これが問題にならないように、実際に触れたクラスにビルドをローカライズする方法も知っている必要があります。
「1週間に1回」実行するように設計されたテストを実施して、継続的な統合を推進するのはおかしいでしょう。代わりに、継続的インテグレーションで実行するように設計された新しいテストを追加し、そこで必要なパフォーマンスに調整します。
これらの新しいテストの派手な用語は次のとおりです 継続的統合テスト 。また、単体テストでもありません。テストを分類する最良の方法は、テストに必要なパフォーマンスに基づいています。それらを実行するために使用するツールではありません。そうすれば、同じように動作するテストが一緒になります。
開発者からテストの制御を奪わないでください。新しい種類のテストを制御できるツールを提供します。
しかし、ビルドが遅すぎるのではないか、またはテストが緊急ビルドを妨げるとどうなるのかという懸念を持ち続けます。
すべきバグのあるコードをコミットしようとしているために緊急ビルドを防止しますが、不正なコードを導入していることを通知するテストを実行しなかったため、発生しません？
チームがテストをツールではなく障害として捉えているようです。テストは彼らの安全策であり、炭鉱のカナリアです。ビルドが遅すぎる場合は、ソフトウェアについて知っておく必要があることを伝えている可能性があります。彼らがじゅうたんの下でスロービルドの問題を解決し続けるなら、それは問題であり続けるでしょう。
まず、単体テストの個別のプロジェクトはgoodです。単体テストコードをメインコードから遠ざけることは、懸念事項の分離と、そういう類の素晴らしいものの分離です。
次に、単体テストがビルドの一部として実行されると処理が遅くなり、ビルドのキューイングが発生する可能性があるという事実から逃れることはできません。ビルドに使用しているもの（TFS、TeamCity、Jenkinsなど）については言及していませんが、複数のキューや優先度など、これを軽減するためにできることがいくつかあります。ビルドマネージャーに話しかけます。
キューをジャンプする必要がある緊急のビルドがある場合は、ビルドマネージャーを最初の呼び出しポートにする必要があります。優先度の高いビルドを低くして、緊急ビルドをキューの上位にプッシュできる場合があります。
最後に、CIについて言及しますが、ゲートされているかどうかについては言及しません。つまり、ビルドまたは単体テストが失敗すると、新しいコード全体が削除されます。コードは理論的には機能するため、これは間違いなく論争になる可能性がありますが、条件によってはテストが失敗する可能性があります。
悲しいかな、銀の弾丸はここにはありません。私がビルドマネージャーだったとき、コードが追い出されたとき、特に締め切りが迫っていたとき、私はしばしば大きな抵抗に遭遇しました。 「TFSがクラッシュし続けます。設定をオフにして、コードをチェックインさせてください！」というリフレインの頻度を聞いた。例外なく、開発者に責任がありました。チェックインにファイルを含めるのを忘れたか、コードが変更されたときにテストの更新に失敗したため、時間がかかりすぎました。
あなたは真剣にここで開発者を押し戻す習慣に入る必要があります。さもなければ、彼らは永遠にあなたの上に粗暴に走ります。別の開発者がうなりを始めたという理由だけで許可した壊れたコードを別の開発者がプルした場合、あなたは人気がありません。
それは、私たちが常にソフトウェア工学で研究している典型的な「変化への抵抗」の問題のためだと思います。単体テストを分離しておくメリットは考えられません（私はJS、Java、.Net、およびABAPで作業してきました）が、「私たちは長い間それを行ってきており、常に機能しており、だから変える必要がある」.
お役に立てば幸いです。本物の理由があるかどうかも知りたいです。
単体テストを個別のプロジェクトとして保持するように要求し続けます
テストは別のプロジェクトで行う必要があります。これは標準的な方法です
mySolution
myProject
myProject.Tests
週に1回程度実行したいだけです。
これは少し奇妙ですが、UIテストの場合は、夜間に実行する可能性があります。しかしながら。同意してテストをチェックインしてください。
「チェックイン時にそれらを実行しないのはなぜですか？」そして、「テストが失敗したときにマージを許可しないのはなぜですか」という会話が後日行われます。