TDD対生産性

現在のプロジェクト（C ++のゲーム）では、開発中にテスト駆動開発を100％使用することにしました。

コードの品質に関しては、これは素晴らしいことです。私のコードはこれほどうまく設計されていないか、バグがありません。プロジェクトの開始時に1年前に書いたコードを見るとき、私はしつこくありません。そして、より簡単にテストできるようにするだけでなく、実装と使用がより簡単になるように、物事を構造化する方法についてより良い感覚を得ました。

しかし...私がプロジェクトを始めてから1年が経ちました。確かに、空き時間にしか作業できませんが、TDDを使用すると、以前と比べてかなり遅くなります。開発の速度が遅くなると時間が経つにつれて良くなることを読み、以前よりもずっと簡単にテストを考え出すことは間違いありませんが、私は1年前からそれをやっていて、まだカタツムリのペースで働いています。

作業が必要な次のステップについて考えるたびに、毎回停止して、実際のコードを書くことができるように、テストをどのように書くかを考えなければなりません。書きたいコードを正確に知っているが、テストで完全にカバーできるほど細かく分解する方法が分からず、何時間も動けなくなることがあります。それ以外の場合は、すぐに12個のテストを考え、テストを書くのに1時間を費やして、さもなければ書くのに数分かかるであろう実際のコードの小さな断片をカバーします。

または、ゲーム内の特定のエンティティとその作成と使用のすべての側面をカバーするために50回目のテストを終了した後、To Doリストを見て、コーディングする次のエンティティを確認し、執筆の思考に恐怖を覚えます実装するための別の50の同様のテスト。

昨年の進捗状況を見ながら、「いまいましいプロジェクトを終わらせる」ためにTDDを放棄することを検討しています。ただし、付属のコード品質を放棄することは、私が楽しみにしていることではありません。テストの作成をやめると、コードをモジュール化してテストしやすくする習慣から抜け出すのが怖いです。

私はおそらくこれで非常に遅いために何か間違ったことをしていますか？メリットを完全に失うことなく生産性を向上させる代替手段はありますか？TAD？テストカバレッジが少ない？すべての生産性と動機を損なうことなく、他の人々はどのようにTDDを生き延びますか？

あなたの経験を共有し、あなたの懸念を表明することに感謝することから始めましょう...私は言わなければならないことは珍しいことではありません。

• 時間/生産性：テストを書くことは、テストを書かないことよりも遅いです。それに範囲を絞るなら、私は同意するでしょう。ただし、TDD以外のアプローチを適用する並列作業を実行する場合、break-detect-debug-and-fixの既存のコードを費やす時間がネットネガティブになる可能性があります。私にとって、TDDは、コードの信頼性を損なうことなく実行できる最速です。メソッドで何かを見つけたとしても、それが価値を高めていない場合は、それらを排除します。
• テストの数：N個をコーディングする場合、N個をテストする必要があります。ケントベックの行の1つを言い換えると、「動作させたい場合にのみテストする」。
• 何時間も動けなくなる：私もやります（ラインを停止する20分以上前のこともあります）..それは、デザインに作業が必要であることを伝えるコードです。テストは、SUTクラスの別のクライアントです。テストでタイプを使用するのが難しいと判断された場合、実稼働クライアントも同様です。
• 同様のテストtedium：これには、反論を書くためにもう少しコンテキストが必要です。つまり、停止して、類似性について考えてください。これらのテストを何らかの方法でデータ駆動できますか？ベースタイプに対するテストを書くことは可能ですか？次に、各派生に対して同じテストセットを実行する必要があります。テストを聞いてください。適切な怠け者になって、退屈を避ける方法を見つけられるかどうかを確認してください。
• 次に行うべきこと（テスト/仕様）について考えるのをやめることは悪いことではありません。それどころか、「正しいこと」を構築することをお勧めします。通常、それをテストする方法が考えられない場合、通常は実装も考えられません。そこにたどり着くまで実装のアイデアを消すのは良い考えです。たぶん、YAGNIのようなプリエンプティブなデザインによって、よりシンプルなソリューションが隠れているかもしれません。

そして、それは私に最終的な質問に連れて行きます：どうすれば良くなりますか？私（またはAn）の答えは、読んで、考えて、練習することです。

例最近、私はタブをつけ続けます

• 私のリズムがRG [Ref] RG [Ref] RG [Ref]を反映しているか、それともRRRRGRRefか。
• 赤/コンパイルエラー状態で費やされた時間の割合。
• Red / Brokenビルド状態で立ち往生していますか？

100％のテストカバレッジは必要ありません。実用的である。

TDDはまだ私をかなり遅くしています

それは実際には間違っています。

TDDを使用しない場合、ほとんど機能するコードの作成に数週間を費やし、翌年には多くの（すべてではない）バグの「テスト」と修正に費やします。

TDDでは、実際に機能するコードを書くのに1年を費やします。その後、数週間にわたって最終的な統合テストを行います。

経過時間はおそらく同じになるでしょう。TDDソフトウェアは、品質が大幅に向上します。

または、ゲーム内の特定のエンティティとその作成と使用のすべての側面をカバーするために50回目のテストを終了した後、To Doリストを見て、コーディングする次のエンティティを確認し、執筆の思考に恐怖を覚えます実装するための別の50の同様のテスト。

これにより、TDDの「リファクタリング」手順をどれだけ実行しているかが気になります。

すべてのテストに合格したら、今度はコードをリファクタリングして重複を削除します。人々は通常これを覚えていますが、これはテストをリファクタリングし、重複を取り除き、物事を単純化するときでもあることを忘れることがあります。

コードの再利用を可能にするために1つにマージする2つのエンティティがある場合、それらのテストもマージすることを検討してください。本当に必要なのは、コードの差分の増分をテストすることだけです。テストのメンテナンスを定期的に実行していないと、テストがすぐに扱いにくくなる可能性があります。

TDDに関するいくつかの哲学的ポイントは、役に立つかもしれません：

• テストの作成経験が豊富であるにもかかわらず、テストの作成方法がわからない場合は、間違いなくコードのにおいです。あなたのコードはモジュール性に何らかの形で欠けているため、小さく単純なテストを書くのが難しくなります。
• TDDを使用する場合、少しのコードをスパイクすることは完全に受け入れられます。目的のコードを記述して、どのように見えるかを理解し、コードを削除してテストから始めます。
• 私は非常に厳しいTDDの練習を運動の一種として見ています。最初に始めるときは、必ず毎回必ず最初にテストを書き、次に進む前にテストに合格するための最も簡単なコードを書いてください。ただし、練習に慣れれば、これは必要ありません。私が書くすべての可能なコードパスのユニットテストはありませんが、経験を通じて、ユニットテストでテストする必要があるもの、機能テストまたは統合テストでカバーできるものを選択することができます。もしあなたがTDDを厳密な方法で1年間練習しているのなら、あなたもこの点に近いと思います。

編集：ユニットテストの哲学のトピックでは、これはあなたが読むのに興味深いかもしれないと思う：テスティウスの道

そして、必ずしも実用的ではないにしても、より実用的なポイントは次のとおりです。

• 開発言語としてC ++に言及しています。JUnitやMockitoなどの優れたライブラリを使用して、JavaでTDDを広範囲に実践しました。ただし、C ++のTDDは、ライブラリ（特に、モックフレームワーク）が利用できないため、非常にイライラすることがわかりました。この点は現在の状況ではあまり役に立ちませんが、TDDを完全に廃止する前に考慮に入れてください。

非常に興味深い質問です。

注意すべき重要なことは、C ++は簡単にテストできないことであり、ゲームは一般にTDDの非常に悪い候補でもあります。OpenGL / DirectXがドライバーXで三角形の赤を描き、ドライバーYで黄色の三角形を簡単に描くかどうかはテストできません。バンプマップの法線ベクトルがシェーダー変換後に反転されない場合。また、異なる精度のドライバーバージョンでクリッピングの問題をテストすることもできません。誤った呼び出しによる未定義の描画動作は、正確なコードレビューとSDKを使用してのみテストすることもできます。音も悪い候補です。ゲームにとって非常に重要なマルチスレッドは、単体テストにはほとんど役に立ちません。大変です。

基本的に、ゲームは多くのGUI、サウンド、スレッドです。GUIは、WM_を送信できる標準コンポーネントであっても、単体テストが困難です。

テストできるのは、モデルの読み込みクラス、テクスチャの読み込みクラス、マトリックスライブラリなどです。これは多くのコードではなく、多くの場合、あまり再利用できません（最初のプロジェクトのみの場合）。また、独自の形式にパックされているため、改造ツールなどをリリースしない限り、サードパーティの入力が大きく異なる可能性はほとんどありません。

繰り返しますが、私はTDDの第一人者でも伝道者でもないので、すべてを塩の粒で取ります。

おそらく、主要なコアコンポーネント（たとえば、マトリックスライブラリ、イメージライブラリ）のテストを作成します。abort()すべての関数に予期しない入力の束を追加します。そして最も重要なことは、簡単に壊れない耐性/復元力のあるコードに集中することです。

1つのエラーについては、C ++、RAII、および優れた設計の巧妙な使用が、それらを防ぐために大いに役立ちます。

基本的に、ゲームをリリースしたい場合、基本をカバーするためにやることがたくさんあります。TDDが役立つかどうかはわかりません。

私は他の答えにも同意しますが、非常に重要な点を追加したいと思います：リファクタリングコスト!!

よく書かれた単体テストを使用すると、コードを安全に書き直すことができます。まず、よく書かれた単体テストは、コードの意図を示す優れたドキュメントを提供します。第二に、リファクタリングの不幸な副作用は、既存のテストスイートで捕捉されます。したがって、古いコードの仮定が新しいコードにも当てはまることを保証しました。

すべての生産性と動機を損なうことなく、他の人々はどのようにTDDを生き延びますか？

これは私の経験とはまったく異なります。あなたは驚くほど頭が良く、バグのないコードを書く（例えば、エラーが1つずれている）か、コードがプログラムの動作を妨げるバグを持っていることに気づかないので、実際には終了していません。

TDDは、あなた（そして私も！）が間違いを犯したことを謙虚に知ることです。

私にとって、ユニットテストを書く時間は、TDDを最初から使用して行われるプロジェクトのデバッグ時間を短縮することで節約できます。

間違いを犯さなければ、TDDは私にとって重要ではないでしょう。

私はほんの少数の発言をしました：

1. すべてをテストしようとしているようです。特定のコード/メソッドの高リスクおよびエッジケースだけを行うべきではありません。ここでは80/20のルールが適用されると確信しています。80％が、カバーされていないコードまたはケースの最後の20％のテストの作成に費やしています。

2. 優先順位を付けます。アジャイルなソフトウェア開発に入り、1か月以内にリリースするために本当に本当に必要なことのリストを作成します。次に、そのようにリリースします。これにより、機能の優先順位について考えるようになります。ええ、あなたのキャラクターがバク転をすることができればクールですが、ビジネス価値はありますか？

TDDは優れていますが、100％のテストカバレッジを目指していない場合のみであり、実際のビジネス価値（つまり、機能、ゲームに何かを追加するもの）の生成を妨げない場合はそうではありません。

はい、テストとコードの作成はコードの作成よりも時間がかかる場合がありますが、コードと関連する単体テスト（TDDを使用）の作成は、コードを作成してデバッグするよりもはるかに予測可能です。

TDDを使用すると、デバッグはほとんどなくなります。これにより、すべての開発プロセスがはるかに予測可能になり、最終的にはより高速になります。

継続的なリファクタリング-包括的な単体テストスイートなしで深刻なリファクタリングを行うことは不可能です。そのユニットテストベースのセーフティネットを構築する最も効率的な方法は、TDD中です。適切にリファクタリングされたコードは、コードを保守するデザイナー/チームの全体的な生産性を大幅に向上させます。

ゲームの範囲を狭めて、誰かがプレイできる場所、またはリリースする場所を取得することを検討してください。ゲームをリリースするのにあまり長く待たずにテスト基準を維持することは、やる気を維持するための妥協点になります。ユーザーからのフィードバックは、長期的に利益をもたらす可能性があり、テストにより、追加や変更に慣れることができます。