自動化された単体テストをビルドの一部にする必要がありますか？
自動化された単体テストをビルドプロセスの一部にする必要がありますか、それとも、誰かがコードを変更したときに手動で実行する必要がありますか？
私にとっては、手動プロセスのままにするのではなく、ビルドの一部にするように見えますが、いくつかの明確な利点があります。ビルドでテストを実行すると、テストがより頻繁に実行され、コードとの同期が取れなくなります。
ビルドでそれらを実行することの欠点は、ビルド時間が増加し、ビルドが失敗する可能性があることですが、完了までに数百秒以上かかるテストは良いテストではないという印象を受けました。また、テストのためにビルドが失敗した場合、それは良いことではないでしょうか？壊れたコードをデプロイするのを防ぎます。
テストをビルドの一部として直接実行している人はあまりいないので、なぜ通常は別々になっているのかと思います。
免責事項：私はテストに関して純粋主義者ではありません。私はTDDを行うのが好きですが、すべてのプロジェクトで100％のカバー率が必要であるとは思いません。
とはいえ、経験則は "すべての変更は、本番環境に移行する前にテストおよび承認する必要があります"である必要があります。
つまり、コミット後（Jenkins、TFSなどの継続的インテグレーションツールによって自動的にトリガーされる）、またはビルドの事前展開フェーズ中にテストを実行できます。
個人的には、自分のマシンで実行するすべてのビルドに対して実行中のテストが退屈であり、テストの実行中に他の雑用に簡単に「ドリフトオフ」させることができます。
そうは言っても、実稼働に移行するコードは私のマシンから直接来るものではなく、それらはすべてCI /ビルドマシンから移行します。これにより、「私のマシンでのみ機能する」というスタンプが私のコードにないことが保証されます。
大規模なチームの場合、ビルドブレーカーを早期に特定し、チームがより早く回復して通信できるようにするために、コミット後のテストがより良い戦略である可能性がありますが、そのためにはサーバーリソースがさらに必要になるでしょう。
小規模で十分に油を塗ったチームで、UAT /本番環境への事前展開テストを行うことで、品質を保証するのに十分かもしれません。
いくつかの経験則を覚えておいてください：
- コミットされていないコードは存在しないコードです。
- テストされていないコードは本番環境に移行しないでください。
- マシンはビルドを生成しません。CI統合サーバーは生成します。
自動化された単体テストをビルドプロセスの一部にする必要がありますか、それとも、誰かがコードを変更したときに手動で実行する必要がありますか？
両方とも。
UnitTestsは個人の開発者と統合プロセスの両方のセーフティネットです。
個人開発者は、UnitTestsを実行して、彼が書いたコードが実際に目的の動作を実装し、既存の目的の動作を壊していないことを確認します。
統合プロセスは、UnitTestsを実行して、異なる開発パスをマージしても目的の動作が中断されなかったことを確認します。
それらを別のビルドターゲットにします：make unit。このように、開発者がコンパイルのみを希望するのか、単体テストも希望するのかを決定するのは開発者の責任です。常にすべてのユニットテストを実行することは意味がない場合があるため、特定のサブモジュールに対してのみユニットテストを実行するメカニズムがあることを確認してください。
継続的インテグレーションビルド（Jenkinsなど）の一部として、すべての単体テストも実行します。そして、1つの失敗が残りのテストを停止しないモードでそれらを実行します。しかしながら、 make unitは最初の失敗で停止できます。
ユニットテストの実行に1〜2秒もかからない場合は、実行してください。それ以外の場合はしないでください。アプリケーションのビルドには、IMOに時間がかかることはありません。ビルドするたびにフォーカスが失われるためです。
単体テストに合格しない場合、ビルドは失敗するはずです。それは品質を強化します。一部の機能が意図したとおりに機能しないビルドはどのように役立ちますか？
さらに、単体テストの実行を忘れないようにします。または、金曜日の5時のビルドのテストを自発的にスキップすることを防ぎます。
はい。 ：Dしかし、万能の答えはありません。
しかし、適切なテスト自動化は、アドホックユニットテストよりも前に常により多くの問題を検出し、より大きな問題からあなたを救います。そして、覚えておいてください。リリース用にビルドしていないのであれば、最新の変更をテストするためにビルドしているのですね。
プロジェクトのサイズに応じて、追加の時間が無視できる場合は、すべての単体テストをプライベートビルドの一部として実行することを選択する必要があります。ただし、1分のビルドに10秒以上、1秒のビルドに2秒以上を追加することは、おそらくお勧めできません。その場合、各プライベートビルドで実行する最も重要な機能の健全性テストを行う、1つまたは2つの簡単な単体テストを特定することができます。
ただし、VCSからプルできるビルドサーバーがあるとすぐに、新しいビルドが成功するたびに「すべて」の単体テストを実行する機能を追加する必要があります。 「すべて」に時間がかかりすぎる場合を除き、つまり、1日あたりのビルド数、平均ビルド時間、単体テスト時間に要約されます。プロジェクトが成長するにつれて、コードベースの無関係な部分を単体テストする必要がないように、ビルドをモジュール化する必要があることがわかります。
テストケースをいかに巧妙に設計しても、処理が集中する場合や、チェックするためにリアルタイムを必要とする場合であっても、reallyには長い時間がかかる重要なユースケースが必然的に見つかります。そのため、それらのケースでは、条件付き、または手動の呼び出しも必要になります。