ユニットテストの前または後にコードレビューを実行する必要があります

ユニットテストの前または後に、コードレビューをいつ実行するかについて同僚と議論しています。ベストプラクティスは何ですか？

考慮に入れる必要があるいくつかの要因（さらにある場合があります）：

• コード変更のサイズ-大きな変更は、コードレビューからさらに多くの変更が行われることを意味します。これらの変更が大きい場合、UTがコードレビューの前だった場合は、ほとんどのUTを再度繰り返す必要があります。
• 単体テストの実行に必要な時間
• 新しい機能ですか、それともバグ修正ですか

コードレビューを行う前に、常にユニットテストを行う必要があります。その理由は次のとおりです。

1. ユニットテストで捕捉されるような方法でコードが破損している場合は、他の開発者をred / green / refactorサイクルに関与させることにより、時間を無駄にすることになります。
2. テストは、他の開発者がコードの意図された使用を示し、レビューを容易にします。
3. テストは、テストケースがない場合やテストが適切に機能しない場合にテストされるコードとともに確認する必要があります。
4. テストとコードレビューでは、見つかった問題の重複が少ししかないさまざまな問題を検出する傾向があります。ユニットテストでは、レビュー担当者が問題を見つけたときにコードを再テストする必要がなく、開発者もイライラします。

おそらく他の理由もありますが、私が個人的に見て経験したのは、3つの異なるチーム/企業内でコードレビューの実践を実装したことです。

編集 もちろん、上記はコードレビューがソフトウェア開発プロセス（ウォーターフォールかアジャイルかに関係なく）のステップである場合のものです。コードの特に大きなセクションや難しいセクションで作業している場合は、いつでも別のペアに注目してください。

コードレビューは、コードが「完了」したときのものです。

私の組織では、「完了」の定義に単体テスト（TDDを目的としているため）が含まれているため、コードレビューは完全なコードであり、完全なコードにはテストが含まれています。

また、テストはレビューとリファクタリングを必要とするため、コードレビューの一部であることは理にかなっています。

テストは、レビューするコードの一部と見なされます。したがって、テストが完了した後でレビューすることは理にかなっています。

テストもレビューされていることを確認します。これは、単体テストを初めて使用するユーザーにとって重要です。

チームが依存性注入、分離フレームワーク、モックとスタブ、シーム、相互作用と状態ベースのテスト、統合とユニットテストを確実に理解するようにします。

前述のトピックを実装する必要はありませんが、それらを理解する必要があります。

上手、

これは、「単体テスト」の意味によって異なります...

TDDスタイルの単体テストの場合は、コードを記述しながらテストを記述するため、意味がありません。後のケースはありません。この場合、コードの品質を継続的に改善します。リファクタリング...

そして

それが古典的な「単体テスト」だった場合[何を意味するのかわからないが、コードを記述して通常は他の人が行った後のテストを意味する]主な基準は、コードレビューと単体テストの性質から期待するものです。迅速なフィードバックを確認してアクションを実行し、自動化された単体テストがない場合は、単体テストを待つ必要があります。コードレビューで成熟した問題を特定し、次の反復のためにソリューションを段階的に適用したい場合は、ユニットテストの前に行うことができます...

しかし結局のところ、個人的には、コードレビューの場合、後または後の単体テストは私にとって実際の基準ではありません...

なぜcodereviewを行うのですか？コード品質について...「品質管理」ゲートの代わりに、ソフトウェア開発プロセス環境に品質を注入します...

私は「アジャイル」にしようと言いがちです...コードが完成して、非公式のコードレビューが迅速に行われるのを待たないでください。実際に全体を待つことができる開発者がいます。コード+テストフェーズが終了する... しかし

本当に新しいテーマ（まったく新しい機能、研究に近い、チームにとってまったく新しいもの）、コードレビューを早期に行う、時間を無駄にしない：同僚に時々見てもらう：分離が重要な要素この場合の失敗。

開発者がチームの初心者でもある場合は、コードを早期に、場合によっては頻繁に確認してください。

ところで、単体テストにもコードのレビューが必要です。