コードレビュー中にテストを書くことは有益ではないでしょうか？
私の同僚は私が面白いと思ったアイデアを思いつきました。
TDDを行わないと想定してレビューを行う人がコードレビュー中にテストを記述することは有益ではないでしょうか？
この質問では、これは純粋にアカデミックなプロジェクトであり、生命にかかわるものはないと仮定します。さらに、チームは4人です。誰もが言語を知っており、使用されるすべてのツール/ライブラリ/フレームワークに精通しており、テストを作成できます。つまり、基本的に上級のフルスタックではない人々は忍者エンジニアではなくまともなコーダーをリードしています。
私が見つけた長所：
- レビュー中にコードをより深く理解して、意味のあるテストを作成するように促します。
- 次に、テストするコードの作成者が行ったテストのコードレビューを追加できます。
私が見つけた短所：
- コードの作成とテストの間のフィードバックループが大きくなります。
編集：「通常の」Webアプリケーションではうまく機能しないことを知っています。私が念頭に置いていたのは、細部に注意を払う必要がある複雑で科学的なアルゴリズムを実装するコーナーケースです。私自身のグラフライブラリ、NLPなどを実装するようなものを想定してみましょう。作成しているコードがデータベースなどから分離されているかどうかはわかりますが、理解するのが非常に難しいため、追加の制御レベルはありません。ソースを理解する必要がある他の人コードを記述して意味のあるテストを行うと、アプリケーション全体をクラッシュさせず、最終的に結果をゴミにしてしまうような、それほど明白ではないバグがプロセス全体で発生しにくくなりますか？
レビューを行う人がコードレビュー中にテストを書くことは有益ではないでしょうか？
テストを書くのに適したタイミングは、状況のテストが必要だと気づいたときです。
コンピュータのタスク切り替えは高価です-人間にとってはそれ以上です。
この時点で、通常、テストの要件と依存関係を十分に理解しています。したがって、問題へのチームの没頭を活用してください。今後、新しいテストを改良する必要がある場合は、テストフレームワーク/フィクスチャがすでに用意されており、改善が必要な部分を変更するだけで済みます。
コードレビュー中にそれが発生した場合は、どうしてそれを実行しないのですか？私は以前にそれをやったことがあります。私はそれが特にあなたがそれを迅速に行うことができればそうでないよりも良いことを発見しました、そしてあなたが他の方法でそれをしなかったならばさらにより良いことを発見しました。
TDDを行わないと仮定しますか？
TDDを実践している場合でも、コードレビューの実行中にテストが必要であることに気付いた場合は、そのテストがないため、その場でテストを作成してみませんか？
長所
- レビュー中のコードに焦点を当てます。
- 時々、コードレビューは人々がそれに夢中でないとき、たまり場とチャット時間になります。テストを書くことは、誰もがレビューされているコードについてより積極的に考えることを奨励します。
- チームのより若いメンバーには、テストライティングの経験から学ぶ機会があります。
- あなたは自分が持っていると知らなかったチームの才能を特定するかもしれません。
より多くのテストがより多くのコードにつながるかもしれないことは本当に悪いことですか？テストが必要であり、テストにコードが必要であり、今それを持っている場合、それはgoodのことです。
注意事項
たぶん一部のチームは他のことに集中する必要があります。優先順位の邪魔になる場合や、コードのレビューが予定を超える場合は、テストの実際の記述を制限またはカットする必要があります。ただし、コードレビューでは、作成する必要のあるテストを確実に特定できます。また、少なくともライターを後で完成させるために、それらをスタブすることができます。
これは素晴らしいアイデアですが、注意点が1つあります。開発者が作成したテストをレビューアが作成したテストに置き換えないでください。コードを壊すコーナーケースと入力をレビュアーに探してもらいます。つまり、元の開発者が書いたとは思わなかった新しいテストを書いてもらいます。
特性評価テストを書くことは、あなたが書いていないコードの一部を理解するための絶対に素晴らしい方法です。レビュー担当者にコードで追加のテストを実施してもらうことで、コードの機能、破損の仕方、および改善の仕方について、理解を深めることができます。その間、コードカバレッジを増やします。
これらはすべて私の本での勝利です。
このアイデアに完全にメリットがないとは思いませんが、TDDらの主な利点は、問題が見つかることですearly。また、開発者は、特別な注意を必要とする可能性のあるコーナーケースを見つけるのに最適です。これをコードレビューまで残しておくと、この知識が失われる可能性があります。
コードレビュー中にテストを作成すると、従来の手動テストと同じ問題が発生します。ビジネスルールの理解は、勤勉さと同様に、開発者によって異なります。
より深刻なバグを捕らえるはずの上流にテスト機能があることを知っていれば、開発者がコードをうまくテストするかどうかについて、古くからある議論もあります。
@RobbieDeeの回答に同意しますが、もう少し追加する必要があります。
このアイデアが本当に好きなら、同じ人に、ユーザーストーリーの実行可能な受け入れ基準として、コードの前にテストを書いてもらいませんか？
それは同じことを行い、フィードバックを短くして、全員がストーリーについて議論するようにします。これはより大きな価値があると思います。
不利な点は、受け入れ基準が無限に満たされる危険性です:-(そして、コードレビューで実装コードを見てもらいたいと思っていると思いますが、ペアプログラミングと回転ペアをより良い解決策として提案することをお勧めします。その問題。
OPは編集を追加しました。編集が追加されたため、これは難しい機能であり、アルゴリズムが重い機能であることがわかります。
それに応えて、問題と解決策にもっと目を向けるあなたの本能は良いと付け加えます。多分、全員が本当に難しい実装コードとテストを見るまで、複数の人と1対1でペアを組むことになるでしょう。それぞれが新しいアイデアを出し、より多くの価値を追加します。
ペアリングのように、より多くの人と一緒に、mob-programmingと呼ぶことがあるアイデアがあります。これは、あなたが話していることとほとんど同じですが、後で正式なレビューを行うのではなく、執筆時に役立ちます。これはすべての人に適しているわけではなく、機能させるには強力なドライバー（リーダー）、またはお互いとプロセスに非常に慣れているチームが必要になる場合があります。
事後の暴徒プログラミングを行うことは、多くの目が問題を見て改善を提案するのと同じ利点の多くを持っていると思います、そしてそれがあなたのチームが快適に操作できる方法であるなら、それは助けることができますが、私は本当に必要なものを維持しようとしますチームの速度を落とす可能性があると思うので、これの発生を最小限に抑えます。
あなたが言うように、TDDチームを運営している場合、コードはすでにテストされているはずなので、これは意味がありません。
全体的にこれはそれほど素晴らしいアイデアだとは思いませんが、それは現在のアプローチと何がうまくいくかに依存します。基本的に、私が見る問題は、テストの「短いフィードバックループ」の利点を失うことです。新しいコードを書いているときに何かを壊した瞬間に即座に通知を受け取ることは、テストが本当に素晴らしい場所です。コードレビューまでテストを延期する場合、基本的には「この問題をより短時間で、関係者が少なくなるように修正できたはずですが、少なくとも何かは（たぶん）学んだ」と言っています。私は、人々がテスト済みのコードをレビューのために提出することを確認して、テストの正確性と保守性を判断することを望みます。結局のところ、コードレビューはコードを記述するためではなく、レビューのためのものです。
一方、レビュー中はテスト/コードをいじってみることをお勧めします。何かを壊してみてください。 if条件をコメント化します。ブール値をリテラルのtrue/falseに置き換えます。テストが失敗しているかどうかを確認します。
しかし、そうです、全体として、コードと一緒にテストを記述して、一度にすべてを確認することをお勧めします。
コードレビューで何をしているのかによります。その段階でテストを作成する主な理由は2つあると思います。
最初に、コードレビュー中にリファクタリングも行い、適用するリファクタリングの種類をカバーするのに十分な単体テストがないことに気付いた場合は、そのようなテストを追加します。
次に、コードにバグがあるように見え、それを証明（または反証）したい場合は、テストを記述します。
どちらの場合も、現時点では存在しないはずのテストの必要性を示しています。もちろん、これらの種類のテストをレビュー担当者または元の作成者が作成する必要があるかどうかは、チームのカルチャーに依存しますが、誰かがテストを作成する必要があります。
実際、これは「複雑な科学的アルゴリズム」にぴったりの「コーナーケース」ではないと思います。まったく逆に、これは、ある程度の品質を期待するあらゆる種類のソフトウェアに適しています。
いいえ、実行しないでください。 TDDは恐ろしいと彼らに思わせるでしょう。
@ k3bは質問のコメントにそれがあると思います。 TDDスタイルのプロセスで記述されたコードは、テストなしで記述されたコードとは外観や相互作用が大きく異なる傾向があります。テストされていないコードに（適切な）テストを追加するには、通常、コードのリファクタリングに多くの目的があり、その意図と可動部分を明確にしています。
コードを記述した後にテストを追加すると、TDDの利点のアーキテクチャー的な側面を見落とすことになります（私の心には、これが主要な利点の1つです）。それだけでなく、コードにあまり慣れていない誰かに、すでに追加するのが難しいテストを追加することを依頼してください。
テストを追加する人は、コードを大幅にリファクタリングする必要があるか、テスト不可能なコードをテストするために非常に努力する必要があります。いずれにせよ、彼らはその経験を楽しむつもりはありません。これは古典的なTDDではないかもしれませんが、そのように見えないので、一度TDDを延期することができます。
（TDDプロセスを既に実行している場合、コードレビュー中に追加テストを記述してもそれほど害はありませんが、私の経験では、テストが既に適切に記述されている場合は、簡単に説明できますレビューのためにコードを提出する人に追加のテストをしてもらい、彼らに書いてもらいます。）
コードレビュー中の単体テストは、開発中の単体テストの代替としては不十分です。
あなたが提案していることは、直感的に、非常に理にかなっています。レビューの目的は何ですか？コードが正しいことを確認するため。テストとは何ですか？コードが正しいことを確認するため。では、なぜこの2つを組み合わせないのでしょうか。
これが理由です。
テスト対象のコードを導入するのは大変な作業です。動作するというコードを書くことは、意図したことの1つだけです。効果的かつ効率的に実行できるコードを書くtestedは別です。コードが「実際の作業」と「テスト」の2つのシナリオで実行されるという事実だけでも、はるかに高い柔軟性が要求され、そのコードは意味のある方法で独自に機能できることが要求されます。
テスト可能なようにコードを記述することは、追加の作業とスキルです。誰かをリファクタリングするelse'sテスト容易性のためのコードは、そもそもテスト可能性を念頭に置いて書かれていない場合、主要な作業になる可能性があります。
開発者とレビュー担当者の間で作業が重複しています。おそらく、開発者は少なくともコードなしでコードをレビューのために提出していませんsome機能していると確信しています。 彼はすでにコードをテストする必要があります。現在、さまざまなレベルとテストの範囲があります。 QAは、開発者andレビュー担当者の後にコードをテストします。しかし、開発者とレビュアーにとって適切と考えるスコープが何であれ、開発者がそのレベルまでコードをテストする方法を理解することは意味がありませんonceが、テストを使い捨てにし、再現を困難にします。次にレビュー担当者を招いてテストを作成します再度、今回は自動化された再現可能なテストを作成します。あなたは両方を持っているだけで、同じテストを書くために時間を費やしています。
レビューをより長く、より面倒なステップに変えています。テストがレビュープロセスの主要な部分である場合、一部のテストが失敗するとどうなるか？レビューアはテストをすべて実行する責任があるので、コードもデバッグする必要がありますか？それとも、1つはテストを記述し、もう1つはテストに合格するように、前後にピンポンしますか？
互いに直交する一連のテストを記述できる場合があるので、ピンポンする必要はありません。レビューアーは12個のテストを作成し、その半分は失敗し、開発者はバグを修正し、すべてのテストは有効のままで、今は合格です。しかし...多くの場合、ブロッカーのバグ、または再設計とAPIの変更を必要とするバグなどがあります。レビュー担当者と開発者の間でテストをやり取りする責任を負うのであれば、実際にはレビュー段階ではありません。あなたはまだ開発中です。
テストを書く必要があるからといって、徹底的なレビューが奨励されるわけではありません。基本的には、深く行くほど、より多くのテストを記述しなければならないことを意味しますhardシステムに深く入り込む必要があるテスト。
テストを作成する開発者と比較して、彼のインセンティブは、重要なテストを作成しない場合、レビュー担当者がレビューで指摘することです。
reviewerでも、システムをより深く理解する必要がある場合、[コードの完全なテスト]を使用すると、いつ停止できるかを自分で決める必要がある場合でも、システムをよりよく理解できます深掘りテストを作成して、コードレビューを確認します。
開発者が単体テストを作成していない場合、レビュー担当者も作成しません。テストを一般的な方法として採用するには、多くの障害があります。多分あなたはあまりにも多くのプレッシャーにさらされており、コードベースをテストするのは難しいです。たぶん、あなたはテストの経験があまりなく、学習曲線に余裕がないと感じているかもしれません。テストを書いている人に脅迫的なメモを送る斧殺人犯がいるのかもしれません。知りません！
しかし、原因が何であれ、レビュアーと開発者の両方に等しく当てはまることは間違いありません。チームがストレスを感じている場合、レビュアーは開発者よりも時間がありません（もしそうであれば、作業を再配布して、人々がそれほどストレスを受けないようにする）。ユニットテストの記述方法がだれにもわからない場合、レビュアーもおそらくそうではありません（もしそうなら、座ってチームメートに教える）。
この提案は、1人の同僚から別の同僚に金を渡そうとしているように聞こえます。そして、私はそれがうまくいく方法をまったく見ていません最初に何よりも一人だけがテストを行うことができる状況を作成することは本当に難しい（そして不健康な）ので、他の人はテストをまったく行えません。
何がdoes仕事であるかレビューカバーテストもある開発者がすでに10個のテストを作成している場合、レビュー担当者が別の10個のテストを提案できるのは、開発者は何も書いていない。
また、コーナーケースのテストが主要なタスクである場合、チーム全体にそれをより広く配布することは理にかなっています。 **コードが最初にテスト可能になると、moreテストの記述がはるかに簡単になります。 **
レビューはspotの重要なケースに最適です。そして、レビュアーがジャンプして、彼女が見つけたコーナーケースのテストを書くことができれば、ねえ、それはなお良いことです。しかし一般的に言えば、レビューアが開発者[ddn't]が非常に貧弱なアイデアのように聞こえる場所でテストを書くことができると仮定します。