方法論：別の開発者のための単体テストの作成
ソフトウェア開発と単体テストの作成について考えていました。私は次のアイデアを得ました：
開発者のペアがいるとします。各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目はそのための単体テストを記述します。テストはコードの後に書かれています。私の考えでは、彼らは互いに助け合うが、別々に働く。理想的には、同じようなサイズの2つの機能に取り組み、テストの準備と交換します。
このアイデアにはいくつかの利点があると思います。
- テストは、実装についての詳細を見ることができる誰かによって書かれています。
- 仕事はペアプログラミングより少し速くする必要があります（同時に2つの機能）、
- テストとコードの両方に責任者がいて、
- コードは少なくとも2人でテストされ、
- 多分あなたのコードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書くための特別な動機を与えて、コーナーを切るのを避けるでしょう。
コード開発とテスト開発の間のコードレビューのために別の開発者を追加することも良いアイデアかもしれません。
このアイデアの欠点は何ですか？それはすでにいくつかの未知の方法論として記述され、ソフトウェア開発で使用されていますか？
PS。私はプロのプロジェクトマネージャーではありませんが、プロジェクト開発プロセスについてある程度の知識があり、最も人気のある方法論をいくつか知っています。しかし、この考えは私にはなじみのないものです。
ペアを使用して製品コードを作成し、それに関連する単体テストを作成する作業を分割する一般的なアプローチは、珍しいことではありません。私は以前にも、このように個人的にペアリングして、かなり成功しています。ただし、プロダクションコードを書く人とテストコードを書く人の間の厳密な境界は、必ずしも結果をもたらすとは限りません。
私が同様のアプローチを使用した場合、ペアはまず問題について話し、共通の理解を得ることから始まります。 TDDを使用している場合は、最初にいくつかの基本的なテストから始めることができます。 TDDを使用していない場合は、おそらくメソッド定義から始めます。ここから、ペアの両方のメンバーがプロダクションコードとテストコードの両方で作業し、1人が各側面に焦点を当てますが、プロダクションコードとその背後にあるテストコードを改善する方法について話します。
各ペアに2つの機能を与えることの利点はわかりません。最終的には、一部の機能についてはTDDに似ているものと、他の機能についてはそうでないものがあります。あなたは焦点を失う。リアルタイムのピアレビューのメリットはありません。ペアリングの主なメリットはありません。
ペアプログラミングの実践は、速度ではなく品質です。したがって、高速化によって推進される修正された手法を使用しようとすると、本質に逆行します。並行コードレビューとテスト開発を介して高品質のソフトウェアを構築することで、各変更について少なくとも2人の知識があり、ピアレビューとテストの待機サイクルを排除（または削減）するため、最終的には時間を節約できます。
あなたのアイデアの主な問題は、コードのテストを書くだけではできないということです。コードはテスト可能でなければなりません。
つまりモックを注入したり、テストしたいビットを分離したり、変更された状態にアクセスしたり、確認を必要としたりできる必要があります。
運が良かったり、最初にテストを書いたりしない限り、テストを書くということは、コードを少し書き直すことを意味します。そもそも、あなたが最初にコードを書いているのでなければ、遅延、会議、リファクタリングなどを意味します。
ここで私が目にする主な問題は、ユニットレベルで、コードを作成するときにコンパイルしますrun itで、最も明らかなバグをすぐに削除します-コードが不完全でわかっている場合でもユニット、機能、機能の一部のみが実装されています。ユニットのコードを実行するには、実装を呼び出すプログラムの一部が必要です。通常はユニットテストまたは少なくとも部分的なユニットテストです。これは必ずしも「本によるTDDスタイル」ではありません。このようなテストは、テスト対象のコードの後または前に記述できます。
私のユニットの1つのバージョンが「機能完全」であり、すべてのバグがないため、自分でこの方法で見つけることができる場合、それを2人目の人に引き渡して、その人に書いてもらうことは理にかなっています追加単体テスト、または私のコードを確認します。しかし、私には、コンパイラが警告を表示しないとすぐにそれを渡すことは意味がありません。「まだ」機能しない、または機能することについてテスターに詳細を説明する必要があることを知っている場合、それは明らかに早すぎます私はまだそのコードの一部で作業しているので、2時間で異なる。この詳細レベルでこれに必要な通信オーバーヘッドは、メリットとバランスが取れていません。
つまり、2番目の開発者がadditional単体テストを作成することは理にかなっていますが、単体テストを排他的に作成することはできません。
次のいずれかの状況が発生する可能性があるようですが、これらはすべて望ましくありません。
混乱
Ewanが概説したように、CUTをテスト可能にするために変更が必要になる場合があります。変更の理由は、開発者にとって常に明白であるとは限らず（そして意見の不一致を引き起こす可能性があります）、それがまさにテストが最初に書かれる理由です。
競合
開発者Aはコードを完成させてテストしたい場合があります。開発者Bも開発中である可能性があるため、ユニットテストに参加するためにコードを保留するのは控えめです。
コンテキストの切り替え
developer Bは、developer A-活動の変化は代償を伴います。
数十年前から受け入れられている マンパワーを倍にしても開発時間は半減しない。上で概説した要因を考えると、この配置がどのように物事を改善するかを理解するのは困難です。
ペアプログラミング および [〜＃〜] tdd [〜＃〜] と組み合わせて使用すると、これは ピンポンパターン と呼ばれます。
- Aは新しいテストを作成し、失敗したことを確認します。
- Bは、テストに合格するために必要なコードを実装します。
- Bは次のテストを作成し、失敗したことを確認します。
- Aは、テストに合格するために必要なコードを実装します。
等々。運転している人が必要に応じてリファクタリングを行います。
しかし、あなたは両方のプログラマーが異なるコンピューターでコードすることを提案しているようです。個別に行うには、非常に低レベルの仕様が必要になります。これはアジャイル方法論に反します。すべての変更を調整する必要があります。 TDDでは、低レベルの設計をその場で行っており、問題ありません。私はあなたのアプローチがすでにコーディングされたある種のスケルトンを持っている必要があると思います。
とにかく、効率が100％でなくても、新しい方法をテストすることで多くのことを学ぶことができます。あなたはそれをテストし、あなたの実際の経験を共有することができます
私はこのパーティーに遅れますが、何か追加する必要があると思います。
それはすでにいくつかの未知の方法論として記述され、ソフトウェア開発で使用されていますか？
ピアテスト について説明しています。
開発者のペアがいるとします。
ああ、良いol ' ペアプログラミング 。
各ペアはコードの一部を担当します。ペアの1つは機能（コードの記述）を実装し、2つ目はそのための単体テストを記述します。テストはコードの後に書かれています。私の考えでは、彼らは互いに助け合うが、別々に働く。
それはペアプログラミングではありません。
理想的には、同じようなサイズの2つの機能に取り組み、テストの準備と交換します。
それは間違いなくピアテストです。これが それに関するACM論文 です。私はこれをやった。 Peer Review プロセスの正式な部分で作業しました。これは役に立ちますが、テストの最初の行になることは確かにありません。また、古典的なペアプログラミングではありません。
これの別名は Whitebox Testing です。その定義は、誰がテストを行っているかということとは関係ありませんが、テスターがテストしているものの内部の仕組みを見ることができるという事実とは関係ありません。何が出ます。通常、ブラックボックスはQAが行うことです。
テストの最初の行は、コーダーの手にしっかりとかかっています。そうでない場合は、自分でコードを自分でテストしないでください。私は10歳のときからコードをテストしています。私は当時、豪華な単体テストでテストしていなかったかもしれませんが、私のコードはテストされました。実行するたびにテストされました。
ピアテスターに期待するのは、私のテストに追加されるテストです。ピアがコードをレビューしたときにコードで見つけた問題を十分に明確にするテスト。自動テストでこれらの問題を表現することにより、それらが何を意味するのかをはるかに簡単に理解できるようになります。事実、私は自分の主張を理解できない同僚と技術的な会話をしていて、問題を示す最善の方法はユニットテストを書くことだと気づきました。それがピアテストです。
さて、あなたが私のコードをうまく書く前に書かれたテストを私に与えたいなら。要件ドキュメントのように、コンパイルできるほど正式なものはありません。
私はDDT（開発主導のテスト、別名コードの後のテスト）、ペアプログラミング、およびred-green-refactor TDDをそれぞれ数年間行ってきました。ポイントごとにアサーションに応答するには：
テストは、実装の詳細を見ることができる誰かによって書かれています
テストを作成する人は、実装をできる限り詳しく知る必要があります過剰なテストをせずに、カバー率の高いテストを作成します。これの典型的な例は、2つがあなたがテストしようとしているものを証明するとき、3つの入力でテストすることです。彼らはコードを読んで表面的な親しみを得ることができますが、元の開発者が現在の状態に至るまでに何を行ったかを正確に理解することはできません。したがって、コードについての理解は最適ではありません。
仕事はペアプログラミングより少し速くする必要があります（同時に2つの機能）
なぜそう言うのか分かりません。 誰かがテストを書いている間、彼らは新機能に取り組んでいません。 2つの異なるタイプの作業を与えることで、誰かの作業能力を魔法のように2倍にすることはできません。私の経験では、テストを書くことは一般的に製品コードを書くよりも難しいので、別の機能を記述しながら、生産的かつ責任を持って一部のコードのテストに取り組むことはできません。
テストとコードの両方に責任者がいる
まず、tests are code。ビジネステストコードは、ビジネスが恐れずにソフトウェアを変更してください。2番目に、これは、テストや製品コードを書いている人と同じですまたはペアで両方を書き込みます。
コードは少なくとも2人でテストされています
いいえ、テストを書いている人だけがテストします。テストにさらに時間をかけたくない場合は、2で停止するのはなぜですか。
多分あなたのコードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書くための特別な動機を与えて、コーナーを切るのを避けるでしょう。
開発者（上級者でさえ）は、「良い」コードを構成するものとは非常に異なるアイデアを持っています。ある人のコーナーカットは、別の人がコードをできるだけ早く作業するための完全に有効な方法です。これは、システムの非難とゲームのレシピです。
Red-green-refactor TDD（実際には実稼働コードを作成する前に単一のテストを作成し、実行し、失敗することを確認し、実稼働コードを変更のみ、テストを再実行し、テストが成功したことを確認してから、リファクタリングを行います。これらのステップをスキップまたはスワップしないでください）およびコードレビューwork。
このアイデアにはいくつかの利点があると思います。
Letsは1つずつそれらを実行します。
テストは、実装についての詳細を見ることができる誰かによって書かれています。
つまり、最初の開発者がいくつかの実装を書くのに時間を費やしたということです。次に、別の開発者が来てテストを作成し、コードに基づいて推論を行うことで誰がそれが正しいかを知りません。また、コードが何をするかについてのみテストを作成するよりも戦術的な利点をもたらすことを期待しています。実装が正しくない場合、私の意見では、テストを作成するための手助けはまったくないでしょう。
仕事はペアプログラミングより少し速くする必要があります（同時に2つの機能）
両方の開発者が最初の開発を終えると、どちらのコードが正しいかどうか誰もわかりません。これはまだチェックされていないままで、誰もが完了したようにチェックすることはできず、いつ完了するかを予測することもできません。これをTDDと比較します。最初にテストを記述し、次にテストを失敗させ、次にコードを渡します。それは、ますます多くのシナリオをサポートするコードです。それが前進です。
それらを並行して進めると、両方の機能で再利用できるコードが2回記述され、コストが2倍になります。
テストとコードの両方に責任者がいて、
XPによって提案されているように、集合的なコード所有権を調べてください。コードの責任者はさらに多くなります。あなたの目標が開発者間で知識を共有することである場合、なぜそれらを分離しようとしているのですか？
コードは少なくとも2人でテストされています
ペアTDDも。ペアリングするとき、両方の人々は、書かれたコードが適切であるか、それを書かないことに同意する必要があります。その結果、戦いが発生した場合、チームの一部の人々は自我の問題を誤って配置している。
多分あなたのコードをテストしている人が書いたコードのエラーを検索することは、より良いコードを書くための特別な動機を与えて、コーナーを切るのを避けるでしょう。
エラーを検索することは、ある時点で、エラーが発生することを許容したことを意味します。エラーが発生した場合、それらは気付かれませんでした。最初にテストを書くことを拒否することは、エラーを許可することです。
コーナーの切断が意図しない可能性があります。それがペアプログラミングの目的です。ペアの各メンバーは、他の1人が手抜きをしないようにする義務を教えられるべきです。それはあなたのプライドをクローゼットに残して、オフィスを離れるときにそれを取り戻す必要があります。人々が間違いなく厳格であると予想する場合は、一般的な状況を考慮せず、失敗に備えています。
XPは、すべての慣行XPは、互いの欠陥をカバーすることによって互いに補強することから作られています。XP 1つは完璧ではありません。TDDは完璧ではありません。ペアプログラミングは完璧ではありません。集合的なコードの所有権は完璧ではありませんが、すべてがお互いをカバーしています。