私の同僚が、私が面白いと思うアイデアを思いつきました。

TDDを行わないと想定してレビューを行う人が、コードレビュー中にテストを書くことは有益ではないでしょうか。

この質問では、これは純粋にアカデミックなプロジェクトであり、命にかかわることはないと想定しています。さらに、チームは4人です。誰もが言語を知っており、使用されるすべてのツール/ライブラリ/フレームワークに精通しており、テストを書くことができます。したがって、基本的には、上級のフルスタックではない人が忍者のエンジニアをリードしていますが、まともなコーダーです。

私が見つけた長所：

1. レビュー中にコードのより深い理解を促し、意味のあるテストを作成します。
2. 次に、テスト対象のコードの作成者が行ったテストのコードレビューを追加できます。

短所：

1. コードの作成とテストの間のフィードバックループが拡大します。

編集：私はそれが「通常の」Webアプリケーションではうまく動作しないことを知っています。私が念頭に置いていたのは、細部に注意を払う必要のある複雑で科学的なアルゴリズムを実装するコーナーケースです。独自のグラフライブラリ、NLPなどの実装のようなものを想定しましょう。作成しているコードがデータベースから分離されているなど、理解するのが非常に難しいのは、ソースを理解する必要のある他の人ではありませんコードを作成し、意味のあるテストを行い、プロセス全体を、アプリケーションをクラッシュさせず、最終的に結果をゴミにするようなそれほど明白ではないバグを起こしにくくしますか？

レビューを行う人が、コードのレビュー中にテストを書くことは有益ではないでしょうか？

テストを書く良いタイミングは、状況に応じてテストが必要だと気づいたときです。

コンピューターのタスクスイッチングは高価であり、人間にとってもそうです。

この時点で、通常、テストの要件と依存関係を十分に理解しています。チームの問題への没入感を活用してください。将来、新しいテストを改良する必要がある場合は、素晴らしいことです。テストフレームワーク/フィクスチャは既に配置されており、改善が必要な部分を変更するだけです。

コードのレビュー中にそれが発生した場合は、先に進んでください。前にやったことがあります。特に迅速に行うことができる場合はそうであるよりも優れていることがわかりました。

TDDを行わないと仮定しますか？

TDDを実践している場合でも、コードレビューの実行中にテストが必要なことに気付いた場合は、持っていないものをテストしてください。

長所

• レビュー中のコードに焦点を当てます。
• 時々、コードレビューは、人々がそれに参加していないときにハングアウトやチャット時間になることがあります。テストを書くことで、誰もがレビューされるコードについてより積極的に考えるようになります。
• チームのより若いメンバーには、テストライティングの経験から学ぶ機会があります。
• チームの中で、自分が持っていることを知らなかった才能を特定できます。

より多くのテストがより多くのコードにつながる可能性があるということは本当に欠点ですか？テストが必要であり、テストにコードが必要だった場合、そして今あなたはそれを持っているなら、それは良いことです。

注意事項

チームの一部は他のことに集中する必要があるかもしれません。優先順位から注意をそらす原因となったり、コードのレビューが予定を超えたりする場合は、テストの実際の記述を制限または削減する必要があります。ただし、コードレビューによって、作成する必要があるテストを確実に特定できます。おそらく、少なくとも後で書き終えるために書き留めることができます。

これは素晴らしいアイデアですが、1つの注意点があります。開発者が作成したテストをレビュー担当者が作成したテストに置き換えないでください。レビュー担当者に、コードを壊すようなコーナーケースや入力を探してもらいます。言い換えれば、元の開発者が書こうとは思わなかった新しいテストを書こうとさせてください。

特性評価テストを書くことは、あなたが書いていないコードを理解するための非常に素晴らしい方法です。レビュアーにコードで追加のテストを実行してもらうと、コードがどのように機能するか、どのように壊れる可能性があるか、どのように改善できるかについて、よりよく理解できます。その間、コードカバレッジを増やします。

これらはすべて私の本での勝利です。

私はこのアイデアにまったくメリットがないとは思いませんが、TDDなどの主な利点は問題が早期に発見されることです。また、開発者は、どのコーナーケースに特別な注意が必要かを見つけるのに最適です。これがコードレビューまで残っている場合、この知識が失われる可能性があります。

コードレビュー中にテストを書くことは、従来の手動テストと同じ問題に悩まされます-ビジネスルールの理解は、勤勉さができるように開発者によって異なります。

また、より深刻なバグをキャッチするテスト機能がさらにアップストリームにあることを知っていた場合、開発者がコードを非常にうまくテストするかどうかについて、実行され実行される古い議論もあります。

@RobbieDeeの回答に同意しますが、もう少し追加する必要があります。

このアイデアが本当に気に入ったら、コードの前にユーザーストーリーの実行可能な受け入れ基準として同じ人にテストを書いてもらいませんか？

それは同じことをしますが、それでもフィードバックを短く保ち、ストーリーについて全員に議論してもらいます。これはより価値があると思います。

欠点は、無限の受け入れ基準を満たすことの危険性です:-(そして、コードレビューで人々に実装コードを見てもらうことを試みていると思いますが、ペアプログラミングと回転ペアをより良い解決策としてお勧めしますその問題。

OPは編集を追加しました。編集は、これが困難な、またはアルゴリズムの重い機能であるという詳細をレイアウトします。

それに応じて、問題と解決策にもっと目を向けるというあなたの本能は良いと付け加えます。誰もが実装コードとテストの非常に難しい部分を見るまで、複数の人と一対一でペアを組むかもしれません。それぞれが新しいアイデアを投げ出し、付加価値を高めます。

ペアリングのように、より多くの人と一緒に、mob-programmingと呼ばれることもあります。これはほとんどあなたが話していることですが、その後の正式なレビューではなく、執筆時に役立ちます。これは万人向けではなく、それを機能させるために強力なドライバー（リーダー）が必要な場合があります。

モブプログラミングの後に行うことは、多くの目が問題を見て改善を提案するのと同じ利点の多くを持っていると思います、そしてそれがあなたのチームが快適に動作しているなら、それは助けることができますが、私は本当に必要なことを維持しようとしますチームの速度が低下する可能性があると思うので、この発生は最小限に抑えられます。

あなたが言うように、TDDチームを運営している場合、コードはすでにテストされているはずなので、これは意味がありません。

全体として、これはそれほど素晴らしいアイデアではないと思いますが、それはあなたの現在のアプローチと何があなたのために働くかに依存します。基本的に、私が見る問題は、テストの「短いフィードバックループ」の利点を失うことです。新しいコードを書いているときでも、何かを壊した瞬間に即座に通知を受け取ることが、テストの真価を発揮します。コードのレビューまでテストを延期する場合、基本的には「この問題をより短時間で、より少ない人数で解決できましたが、少なくとも何かを学んだかもしれません」と言っています。人々がテスト済みのコードをレビュー用に送信することを確認してから、テストの正確性と保守性を判断してください。結局のところ、コードレビューはコードを書くためではなく、レビューするためのものです。

一方、レビュー中にテスト/コードを修正することをお勧めします。何かを壊してみてください。if条件をコメント化します。ブール値をtrue / falseリテラルに置き換えます。テストが失敗するかどうかを確認します。

しかし、ええ、全体として、コードと一緒にテストを作成し、一度にすべてを確認することをお勧めします。

コードレビューで何をしているかに依存します。その段階でテストを書く主な理由は2つあると思います。

• 最初に、コードレビュー中にリファクタリングも行い、適用したいリファクタリングの種類をカバーするのに十分なユニットテストがないことに気付いたら、そのようなテストを追加します

• 第二に、コードがバグがあるかのように見え、これを証明（または反証）したい場合は、テストを書きます

どちらの場合も、現時点では存在しないテストの必要性を表していますが、そうすべきです。もちろん、これらの種類のテストをレビュー担当者または元の作成者が作成するかどうかはチームの文化に依存しますが、誰かがテストを作成する必要があります。

実際、これは「複雑で科学的なアルゴリズム」に適した「コーナーケース」ではないと思います。まったく逆で、ある程度の品質が期待されるあらゆる種類のソフトウェアに適しています。

いいえ、それをしないでください。TDDが恐ろしいと思わせるでしょう。

@ k3bが質問のコメントにそれがあると思います。TDDスタイルのプロセスを介して記述されたコードは、テストなしで記述されたコードとは非常に異なって見え、相互作用する傾向があります。テストされていないコードに（良い）テストを追加するには、通常、コードをリファクタリングして、その意図と可動部分を明確にします。

コードを書いた後にテストを追加することで、TDDの利点のアーキテクチャーの側面を見逃します（これは私の考えでは大きな利点の1つです）。それだけでなく、コードにあまり精通していない他の誰かに、すでに追加するのが難しいテストを追加するように頼んでいます。

テストを追加する人はコードを大幅にリファクタリングするか、テストできないコードをテストするために非常に一生懸命働く必要があります。いずれにせよ、彼らは経験を楽しむつもりはありません。これは古典的なTDDではないかもしれませんが、彼らはそのようには見えず、TDDを一度だけ延期することができます。

（既にTDDプロセスをフォローしている場合、コードレビュー中に追加のテストを書くことはそれほど有害ではありませんが、私の経験では、テストがすでによく書かれていれば、追加のテストを提出する人に簡単に説明できますレビュー用のコードを作成し、それらに書いてもらいます。）

コードレビュー中のユニットテストは、開発中のユニットテストの貧弱な代替です。

あなたが提案していることは、直感的に多くの意味をなします。レビューは何のためですか？コードが良いことを確認する。テストの目的は何ですか？コードが良いことを確認する。それでは、2つを組み合わせてみませんか？

その理由は次のとおりです。

コードをテストするのは大変な作業です。意図したことだけで機能するコードを記述することは、1つのことです。効果的かつ効率的にテストできるコードを書くことも別の方法です。「実際の作業」と「テスト」という2つのシナリオでコードが実行されるという事実だけでも、はるかに高い柔軟性が必要であり、そのコードが意味のある方法で自立できることが要求されます。

テスト可能なコードを書くことは、余分な作業とスキルです。最初にテスト容易性を念頭に置いて書かれていなかった場合、テスト容易性のために他の誰かのコードをリファクタリングすることは、大きなタスクです。

開発者とレビュアーの間で努力を複製しています。おそらく、開発者は、コードが機能しているという少なくともある程度の自信がなければ、レビューのためにコードを渡していないでしょう。彼はすでにコードをテストする必要があります。現在、テストにはさまざまなレベルと範囲があります。QAは、開発者とレビューアの後、コードをテストします。しかし、開発者とレビュアーにとって適切だと思われるスコープが何であれ、開発者がコードをそのレベルまで一度テストする方法を理解することは意味がありませんが、テストを捨てて再現するのを難しくし、レビュアーをテストを再度開発する、今回は自動化され、再現可能なもの。あなただけ抱えているの両方に一度の悪い、一度うまく-それらのは、同じテストを書くに時間を投資します。

レビューをはるかに長い、より面倒なステップに変えています。テストがレビュープロセスの主要な部分である場合、一部のテストが失敗するとどうなりますか？レビュー担当者はテストをすべて実行する責任があるので、コードもデバッグする必要がありますか？それとも、テストを書いたり、他のテストに合格させたりして、行き来するのでしょうか？

場合によっては、すべて互いに直交する一連のテスト全体を記述できるため、ピンポンする必要はありません。レビュー担当者は多数のテストを作成しますが、そのうちの半分は失敗し、開発者はバグを修正し、すべてのテストは有効なままで、すぐに合格します。しかし...多くの場合、ブロッカーバグ、または再設計とAPIの変更を必要とするバグ、またはその他のバグがあります。レビュー担当者と開発者の間でテストをやり取りする責任を負っている場合、実際にはレビュー段階ではありません。あなたはまだ開発中です。

テストを書く必要があるからといって、より徹底的なレビューを奨励するわけではありません。基本的には、深く掘り下げるほど、より多くのテストを記述する必要があり、おそらくシステムの奥深くに行く必要のある難しいテストになることを意味します。

彼のインセンティブがあるテストを書いている開発者と比較してください。重要なテストを書いていない場合、レビューアはレビューでそれを指摘します。

コードの徹底的なテストに精通する必要がある場合、レビュアーでさえもシステムをよりよく理解できます。そして、掘り下げたテストの作成を停止してコードレビューをOKにできる時期を自分で決定する必要がある場合。

開発者が単体テストを作成していない場合、レビュー担当者も作成しません。一般的な方法としてテストを採用することには多くの障害があります。たぶんあなたはあまりにもプレッシャーにさらされており、コードベースをテストするのは難しいでしょう。たぶん、あなたはテストの経験があまりないので、学習曲線を買う余裕がないと感じます。たぶん、テストを書く人に脅迫的なメモを送信するx殺人者がいるでしょう。知りません！

しかし、原因が何であれ、それがレビュアーと開発者に等しく当てはまることは間違いありません。チームがストレスを感じている場合、レビュー担当者は開発者よりも時間がありません（もしそうなら、人々にストレスがかからないように作業を再配分します）。ユニットテストの書き方をよく知らない人は、おそらくレビュアーもそうではないでしょう（もしそうなら、座ってチームメイトに教えるべきです）。

この提案は、ある同僚から別の同僚に金を渡そうとしているように聞こえます。そして、私はそれがうまくいく方法を見ていません。何よりもまず、テストを行えるのは一人だけで、他の人はできないという状況を作り出すのは本当に難しい（そして不健康な）からです。すべてのテスト。

何んの仕事をされたとしても審査カバーテストを持ちます。開発者が既に10個のテストを作成している場合、開発者が何も作成していない場合よりも、レビューアがさらに10個のテストを提案できる可能性が高くなります。

また、コーナーケースのテストが主要なタスクである場合、チーム全体に広く配布することは理にかなっているかもしれません。**最初にコードがテスト可能になると、より多くのテストを書くことがはるかに簡単になります。**

レビューは、コーナーケースを見つける絶好の機会です。そして、レビュアーが飛び込んで、彼女が見つけたコーナーケースのテストを書くことができたら、ちょっと-いっそう良い！しかし、一般的に言えば、開発者が非常に貧弱なアイデアのように聞こえない場合に、レビュー担当者がテストを作成できると仮定します。