方法論：別の開発者向けの単体テストの作成

私はソフトウェア開発と単体テストの作成について考えていました。私は次のアイデアを得ました：

開発者のペアがあるとしましょう。各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目は機能の単体テストを記述します。テストはコードの後に​​記述されます。私の考えでは、彼らはお互いを助けますが、かなり別々に働きます。理想的には、2つの同様のサイズの機能で動作し、テスト準備のために交換します。

このアイデアにはいくつかの利点があると思います。

• テストは、実装の詳細を確認できる誰かが作成します。
• ペアプログラミング（2つの機能を同時に使用）よりも作業を少し速くする必要があります。
• テストとコードの両方に責任者がいます。
• コードは少なくとも2人でテストされ、
• コードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書いてコーナーを避ける特別な動機付けになるでしょう。

また、コード開発とテスト開発の間にコードレビューのために別の開発者を追加することも良い考えです。

このアイデアの欠点は何ですか？それはすでに私にとって未知の方法論として説明されており、ソフトウェア開発で使用されていますか？

PS。私はプロのプロジェクトマネージャーではありませんが、プロジェクト開発プロセスについては何かを知っており、いくつかの最も一般的な方法論を知っています。

ペアを使用して製品コードの記述とそれに関連する単体テストの記述の労力を分割する一般的なアプローチは珍しくありません。私は以前にもこの方法で個人的にペアを組んで、まともな成功を収めました。ただし、本番コードを書いている人とテストコードを書いている人との間の厳密な線が必ずしも結果をもたらすとは限りません。

私が同様のアプローチを使用したとき、ペアは問題について話し合い、理解を共有することから始めます。TDDを使用している場合、最初にいくつかの基本的なテストから始めることができます。TDDを使用していない場合は、おそらくメソッド定義から始めます。ここから、ペアの両方のメンバーが製品コードとテストコードの両方で作業し、1人がそれぞれの側面に焦点を当てますが、製品コードとその背後のテストコードを改善する方法について話します。

各ペアに2つの機能を提供することの利点がわかりません。最終的には、一部の機能についてはTDDに似たものであり、他の機能についてはそうではないものです。フォーカスを失います。リアルタイムのピアレビューのメリットは得られません。ペアリングの主な利点はありません。

ペアプログラミングの実践は、速度ではなく品質です。したがって、高速化によって駆動される修正された手法を使用しようとすると、自然に反します。並行コードレビューとテスト開発により高品質のソフトウェアを構築することにより、各変更の知識を持つ少なくとも2人のユーザーがいるため、ダウンストリームで時間を節約でき、ピアレビューとテストの待機サイクルを排除（または削減）します。

あなたのアイデアの主な問題は、コードのテストを書くことができないということです。コードはテスト可能でなければなりません。

すなわち、モックを注入し、テストしたいビットを分離し、変更された状態にアクセスし、確認する必要があるなどの必要があります。

運が良かったり、最初にテストを書いたりしない限り、テストを書くことは、コードを少し書き換えることを意味します。そもそもコードを書いている人でなければ、遅延、会議、リファクタリングなどを意味します

ここで私が見ている主な問題は、ユニットレベルで、コードを書くとき、それをコンパイルし、実行し、最も明白なバグをすぐに削除することです -コードが不完全で、ユニット、機能、または機能がわかっている場合でも部分的にのみ実装されています。そして、ユニットのコードを実行するには、実装を呼び出すプログラムの一部、通常はユニットテストまたは少なくとも部分的なユニットテストが必要です。これは必ずしも「本によるTDDスタイル」ではなく、そのようなテストはテスト対象のコードの前後に書くことができます。

私のユニットの1つのバージョンが「機能完了」であり、すべてのバグがない場合、私は自分でこの方法を見つけることができるので、2番目の人に引き渡して追加のユニットテストを書くか、コードをレビューさせるのが理にかなっています。しかし、コンパイラーが警告を表示しなくなったらすぐにそれを渡すことは意味がありません。「まだ」動作しない、または動作することをテスターに​​詳細に説明しなければならないと知っている場合、それは明らかに早すぎます私はまだそのコードで作業しているので、2時間で異なります。その詳細レベルでこれに必要な通信オーバーヘッドは、利益とバランスが取れていません。

そのため、追加の単体テストを作成する2番目のdevを使用するのは理にかなっていますが、単体テストを排他的に作成するためではありません。

次のいずれかの状況が発生する可能性があるように思われますが、これらはすべて望ましくありません。

混乱

Ewanが概説したように、CUTをテスト可能にするには変更が必要になる場合があります。変更の理由は、開発者にとって必ずしも明らかではない（そして意見の相違を引き起こす可能性がある）ため、テストが最初に記述されるのはまさにそのためです。

競合

開発者Aがコードを完成し、テストすることを望んでいる場合があります。開発者Bも開発中である可能性があるため、ユニットテストに参加するためにコードを保留することを控える場合があります。

コンテキスト切り替え

場合でも、開発者Bは、によって書かれたコードをテストするために、その開発を棚上げしていく所存です開発者Aを -活性の変化はコストがかかります。

何十年もの間、人力を2倍にしても開発時間は半減しないことが受け入れられてきました。上記で概説した要因を考慮すると、この配置が物事をどのように改善するかを見るのは困難です。

ペアプログラミングおよびTDDと組み合わせて使用する場合、これはピンポンパターンと呼ばれます。

• Aは新しいテストを作成し、それが失敗することを確認します。
• Bは、テストに合格するために必要なコードを実装します。
• Bは次のテストを作成し、失敗することを確認します。
• Aは、テストに合格するために必要なコードを実装します。

等々。リファクタリングは、運転している人が必要になるたびに行われます。

しかし、両方のプログラマーが異なるコンピューターでコーディングすることを提案するようです。個別に行うには、非常に低いレベルの仕様が必要です。これはアジャイルな方法論に反します。すべての変更を調整する必要があります。TDDでは、低レベルの設計をその場で行いますが、問題はありません。私のアプローチでは、何らかの種類のスケルトンがすでにコーディングされている必要があると思います。

とにかく、100％効率的でなくても、物事の新しい方法をテストすることで多くを学ぶことができます。あなたはそれをテストし、あなたの実生活経験を共有することができます

私はこのパーティーに遅れていますが、何か追加することがあると思います。

それはすでに私にとって未知の方法論として説明されており、ソフトウェア開発で使用されていますか？

あなたは記述されているピアのテストを。

開発者のペアがあるとしましょう。

ああ、良いペアプログラミング。

各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目は機能の単体テストを記述します。テストはコードの後に​​記述されます。私の考えでは、彼らはお互いを助けますが、かなり別々に働きます。

それはペアプログラミングではありません。

理想的には、2つの同様のサイズの機能で動作し、テスト準備のために交換します。

それは間違いなくピアテストです。ここだそれについてのACMの紙が。これをやった。私はピアレビュープロセスの正式な部分で働いてきました。これは便利ですが、テストの最初の行になることを意図したものではなく、従来のペアプログラミングではありません。

これの別名はWhitebox Testingです。その定義は、テスターがテスト対象の内部動作を見ることができるという事実と同じくらい、誰がテストを行っているかということ自体には関係していませんが、何が出る。通常、ブラックボックスはQAの機能です。

テストの最初の行は、コーダーの手にしっかりとかかっています。そうでない場合、あなたは私がコードを自分でテストしないように私に頼んでいますが、私はそれを拒否します。私は10歳のときからコードをテストしています。当時は派手な単体テストでテストしていなかったかもしれませんが、コードはテストされました。実行するたびにテストされました。

ピアテスターに​​期待するのは、テストに追加するテストです。ピアがコードのレビュー時に発見した問題を十分に明らかにするテスト。自動化されたテストでこれらの問題を表現することにより、それらが意味するものをはるかに簡単に理解できます。事実、私は自分の主張を理解できなかった同僚と技術的な会話を交わし、ユニットテストを書くことが問題を示す最良の方法だと気づきました。それがピアテストです。

さて、コードを書く前にテストを書いてもらいたい場合は。コンパイルするほど正式な要件文書のようなものはありません。

私はDDT（開発駆動テスト、別名コード後のテスト）、ペアプログラミング、レッドグリーンリファクタリングTDDをそれぞれ数年間行ってきました。アサーションにポイントごとに応答するには：

テストは、実装に関する詳細を確認できる誰かが作成します。

テストを作成する人は、実装をできるだけ詳しく知って、過剰なテストをせずに適切なカバレッジでテストを作成する必要があります。これの典型的な例は、テストしようとしているものを2つで証明するときに3つの入力でテストすることです。彼らはコードを読んで表面的な知識を得ることができますが、元の開発者が現在の状態に到達するために何を経験したかを正確に理解することはできません。そのため、彼らはコードの理解が最適とは言えません。

作業はペアプログラミングよりも少し速くする必要があります（同時に2つの機能）

なぜあなたがそれを言うのか分かりません。誰かがテストを書いている間、彼らは新しい機能に取り組んでいません。2つの異なるタイプの仕事を与えることで、誰かの仕事の能力を魔法のように倍にすることはできません。私の経験では、テストの作成は一般に本番コードの作成よりも難しいため、別の機能を作成する際にコードのテストに生産的かつ責任を持って取り組むことはできません。

テストとコードの両方に責任者がいます

まず、テストはコードです。ビジネスにとって、テストコードは本番コードとほぼ同じくらい重要です。ビジネスコードを使用すると、恐れることなくソフトウェアを変更できるからです。第二に、これはテストと本番のコードを書いている一人、あるいは両方を書いているペアと違いはありません。

コードは少なくとも2人でテストされています

いいえ、テストを書いている人によってのみテストされます。テストにさらに多くの時間を使いたくなければ、なぜ2つで停止するのですか？

コードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書いてコーナーを避ける特別な動機付けになるでしょう。

開発者（上級者であっても）は、「良い」コードを構成する非常に異なるアイデアを持っています。ある人のコーナーカットは、できるだけ早く作業コードに到達する別の人の完全に有効な方法です。これは、システムを非難し、ゲームをするためのレシピです。

Red-green-refactor TDD（実動コードを作成、実行、失敗、実動コードのみの変更、テストの再実行、成功の確認、リファクタリングの前に単一のテストを実際に記述し、スキップまたはスワップしないこれらの手順）とコードレビューが機能します。

このアイデアにはいくつかの利点があると思います。

それらを1つずつ実行しません。

テストは、実装の詳細を確認できる誰かが作成します。

つまり、最初の開発者が実装を書くのに時間を費やしたということです。次に、別の開発者が来てテストを書きます。その理由はコードが正しいかどうかを誰も知らないので、コードが何をすべきかについてのみテストを書くことに比べて戦術的な利点をもたらすことを望んでいます。実装が正しくない場合、テストの作成に役立つことはないと思われます。

作業はペアプログラミングよりも少し速くする必要があります（同時に2つの機能）

両方の開発者が最初の開発を終了すると、どちらのコードが正しいかは誰にもわかりません。これはまだ確認されていないため、誰も完了したと判断することはできず、いつ完了するかを予測することはできません。これをTDDと比較してください。最初にテストを記述し、次にテストを失敗させ、コードを渡します。それは、より多くのシナリオをサポートするコードです。それは前進です。

それらを並行して進行させると、両方の機能で再利用できるコードが2回書き込まれ、2倍のコストがかかります。

テストとコードの両方に責任者がいます。

XPによって提案されたコードの集合的な所有権を調べてください。コードを担当する人がさらに増えます。開発者間で知識を共有することが目標の場合、なぜそれらを分離しようとしているのですか？

コードは少なくとも2人でテストされています

ペアTDDでも。ペアリングするとき、両方の人は、書かれたコードが適切であるか、書かれていないことに同意しなければなりません。それが戦いにつながる場合、チームの一部の人々は見当違いのエゴ問題を抱えています。

コードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書いてコーナーを避ける特別な動機付けになるでしょう。

エラーを検索するということは、ある時点でエラーが発生することを許容したことを意味します。エラーが発生した場合、それらは気付かれていませんでした。最初にテストを書くことを拒否することは、取得するエラーにライセンスを与えることです。

カットコーナーは意図的でない場合があります。それがペアプログラミングの目的です。ペアの各メンバーは、他の1人にコーナーをカットさせないという義務を負わせる必要があります。それにはクローゼットの中にプライドを残し、オフィスを出るときにそれを取り戻す必要があります。従業員が間違いなく厳格であることを期待する場合、一般的な状況を考慮せず、失敗に備えてください。

XPは、XPのすべてのプラクティスは、互いの欠陥をカバーすることにより相互に強化することで作られていることを明確に述べています。XPの実践を他のものから切り離して批判することは避けてください。完璧なプラクティスはありません。TDDは完璧ではありません。ペアプログラミングは完璧ではありません。集合的なコードの所有権は完璧ではありませんが、それらはすべてお互いをカバーしています。