コードレビューアはレビューの一部としてテストする必要がありますか？
可能性のある複製：
コードレビューの信頼係数
私が働いている場所では、コードレビューを構成するものについてのルールはほとんどありません。コードを確認することに加えて、私がレビューしているソフトウェア（私の場合、それは常に私たちのWebサイトです）を簡単にテストして、少なくともプロジェクトが大きい場合に、明白なエラーがないかどうかを確認する傾向があります。ここのコードレビューアがフィードバックで何も提案していないところから多くの提案を受け取ったが、実際にはサイトがまったくロードされなかったか、単に想定どおりに機能しなかった場合。
また、コードを調べて、セマンティックエラーが発生している可能性があると考えている場合もありますが、確認するためにテストする必要があります。
最後に、コードを見るだけでは明らかではないかもしれない、短いテストでも発生する可能性のある非常に明らかなエラーがいくつかあります（または、おそらく私は単なる劣ったレビュアーです）。さらに、一部の開発者とテスターはソフトウェアの使用方法に関して非常に異なる考え方を持っている可能性があるため、レビュアーはテスターがそうではない（そしてその逆も同様）問題を見つけるかもしれません。
コードレビューは、保守性、セマンティクス、一貫性、標準、さらには構文のエラーをキャッチするための開発プロセスにおける非常に重要なステップだと思います。私が出した質問は次のとおりです。コードレビューアは実際にソフトウェアをテストする必要がありますか？もしそうなら、それは彼らの責任ですか、それともこの実践は開発プロセスの一部として管理されるべきですか？テストする場合、どのくらいのテストが合理的ですか？テストでエラーが見つかった場合、開発者が自分でデバッグするための再現手順を提供するだけでなく、コードを調べてエラーを見つけるのにどのくらいの時間を費やす必要がありますか（ある場合）。
優れたコードレビューでは、コードをそのまま検査します。これは、自分が書いたと信じていることをよく理解している開発者にとって難しい場合があります。
私は私の答えであなたの質問の多くをカバーしました trust-factor-in-code-review 。レビュー中のコードは開発者によってテストされていると思います。さまざまなテストスイートでさらにテストを行う必要があります。それはあなたの特定の質問なので、私はテストを少し拡張します。
私は「いいえ、テストはコードレビュープロセスの一部ではありません」と答えます。ただし、テストよりもコードレビューで見つけやすいエラーのクラスがあります。コードレビューで特定できるエラーが発生しやすいコーディング手法もあります。たとえば、コードレビューでは、自動化が困難な不適切な変数の名前を特定できます。
関連する単体テストを確認することが適切な場合があります。探すべきものは次のとおりです。
- 彼らは重要な機能をテストしていますか？
- 重要な機能をテストしていますか？
- 重要なEdgeケースをテストしますか？
- それらは成功事例を合理的にカバーしていますか？
- 障害のケースを合理的にカバーしていますか？
重要なコードの場合、妥当な時間内にすべての機能をカバーすることはできません。ただし、単体テストでは、コードが機能し、期待どおりに失敗することを確認する必要があります。
ライブラリで利用可能な機能を実装するコードに注意してください。テストケースに加えて、ライブラリコードは使用中にかなりテストされ、重要な最適化と安全性チェックが含まれる場合があります。どちらの方法でも、ライブラリが修正してもプログラマーの実装は修正されません。ライブラリ機能を拡張する必要がある場合は、ラッパーを使用します（プロジェクトまたは組織用に1回開発されました）。 「ここでは発明されていない」テクノロジをできるだけ多く使用します。
レビューを行うと、チェックリストに含めるもののチェックリストが生成されます。これにより、コードレビューを適切に行うことができます。
問題を特定するときに、個人が生成する問題のチェックリストを作成することができます。彼らが行う一般的なエラーのリストを尋ね、それを使用します。リストを彼らと共有し、それらの問題についてその開発者からの将来のコードをチェックしてください。開発者が開発するにつれて、回避したい問題がリストから削除される場合があります。
私の意見では、コード変更のテストカバレッジの程度と、QAチームが実行しているテストの種類によって異なります。レビュー中に、処理されるさまざまな入力をコードで確認できます。テストがこれらすべての入力を正しくカバーしている場合、コードレビューアーが手動でこれらをテストするのは時間の無駄になると思います。ただし、これらの入力の一部（またはすべて）がテストでカバーされていない場合は、ソースにアクセスできないと思われるQAチームがこれらの入力を必ずしもヒットしないため、コードレビューアーがこれらの入力をテストするのが賢明です。彼らのテストのケース。
テストカバレッジが事実上ない場合（たとえば、現在の会社で）、コードレビューアーに機能テストを実行させることは事実上必要であると言えます。
コードレビューに関する要件がほとんどないことに共感しています。それは私の理解でもありますが、理由は思い出せませんが、非構造化コードのレビューはまったく効果的ではありません。コードレビューの Faganメソッド は、コードレビューにとって非常にタイトな構造です。
とは言っても、テストがコードレビューの一部ではない理由を理解することはできません。いくつかのテストを実行しないと、レビュアーはコードのどこに問題があるのか漠然とした疑いを持つだけかもしれません。
コードがコードレビューに到達するまでに、開発者はユニットテストを記述し、レビュー対象のコードとユニットテストの両方を正常に構築し、現在記述されているすべてのユニットテストに合格している必要があります。このため、コードレビューアはコードをテストする必要はありません。コードの作成者は既にテストを行っているはずです。開発者がテストを実行、コンパイル、または合格しないコードレビューのコードを提出する場合、開発者はコードレビューに関与するすべての人の時間を浪費する責任を負うべきです。
とは言え、レビュー対象のコードに対応する単体テストもレビューして、すべての必須のケースがカバーされていること、テストの実行を遅くする無関係のテストケースがないこと、そしておそらくいくつかのことを指摘することは良い考えかもしれません十分な時間やリソースがある場合にカバーする必要がある他のケース。テスト品質の向上は、プロジェクトの全体的な品質を向上させるだけです。