修正後にのみテストできるバグをTDDするにはどうすればよいですか？
これが1つの例です。私のWebアプリケーションにはドラッグ可能な要素が含まれています。要素をドラッグすると、ブラウザは「ゴーストイメージ」を生成します。ドラッグ時に「ゴーストイメージ」を削除したいので、この動作のテストを作成します。
私の問題は、最初はこのバグを修正する方法がわからないことです。テストを記述できる唯一の方法は、修正した後です。
let sum = (a, b) => a - bなどの単純な関数では、コードを記述する前に、sum(1, 2)が3と等しくない理由についてのテストを記述できます。
私が説明している場合、検証とは何なのかわからないので、テストできません（アサーションがどうあるべきかわかりません）。
説明されている問題の解決策は次のとおりです。
let dataTransfer = e.dataTransfer
let canvas = document.createElement('canvas');
canvas.style.opacity = '0';
canvas.style.position = 'absolute';
canvas.style.top = '-1000px';
dataTransfer.effectAllowed = 'none';
document.body.appendChild(canvas);
dataTransfer.setDragImage(canvas, 0, 0);
これが解決策であることを私は知ることができませんでした。オンラインでソリューションを見つけた後、テストを作成することさえできませんでした。それが本当に機能するかどうかを知る唯一の方法は、このコードをコードベースに追加して、目的の効果があるかどうかブラウザーで確認することでした。テストは、TDDに反するコードの後に記述する必要がありました。
この問題に対するTDDのアプローチは何でしょうか？コードの前にテストを書くことは必須ですか、それともオプションですか？
私があなたを正しく理解したとき、「ゴーストイメージ」の例の信頼できる自動テストを書くことさえできません後で解決策を見つけた後、正しい動作を確認するには、画面を見て、ゴーストイメージがないかどうかを確認します。それは私にあなたの元の見出しが間違った質問をしたような印象を与えます。本当の質問は
- グラフィカルユーザーインターフェイスの特定の動作を自動的にテストする方法
そして答えは-Iのいくつかの種類の問題については、あなたはしませんです。確かに、問題を表示するUIを自動化してスクリーンショットの比較のようなものを実装しようとすることもできますが、これは多くの場合エラーが発生しやすく、壊れやすく、費用対効果が高くありません。
特に、「テストドライビング」のUIデザインや、事前に記述された自動テストによるUIの改善は、文字通り不可能です。改善を加えてUIデザインを「推進」し、結果を人間（自分、一部のテスター、またはユーザー）に示し、フィードバックを求めます。
したがって、TDDが特効薬ではないという事実を受け入れてください。ある種の問題については、手動テストは自動テストよりも意味があります。体系的なテストプロセスがある場合は、専任のテスターがいる場合、テスト計画にケースを追加するのが最善の方法です。
この問題に対するTDDのアプローチは何でしょうか？コードの前にテストを書くことは必須ですか、それともオプションですか？
1つの方法は スパイクソリューション の類似体を適用することです。
James Shore は次のように説明しています：
さらに情報が必要な場合は、小規模で孤立した実験を行います。
基本的な考え方は、何が起こっているのかを理解している間にdesignツールを置くことです。ベアリングを入手したら、設計ツールを再び受け取ります。
トリック：knowledgeを調査から本番コードベースに戻しますが、コード。代わりに、規律のある設計手法を使用しながら再作成します。
コース用の馬。
編集：
欠陥が人間の目でしか見えない場合、どのようにしてテストを自動化できますか？
少し異なるスペルを提案したいと思います。「テストの自動化が費用効果が高くない場合、どうすればテストを自動化できますか？」
もちろん、答えは「あなたはしない」です。代わりに、実装を2つの部分（テストが費用対効果の高い大きな部分と、単純すぎて分割できない小さな部分）に分離するように努めてください。
ソフトウェア設計を構築する方法は2つあります。1つは、単純化して欠陥がないことを明らかにすることです。C.A.R。ホアレ
したがって、サードパーティのコードを操作する場合、サードパーティのライブラリのプロキシとして機能する非常に薄いコードのシェルが作成されます。テストでは、そのシェルを「テストダブル」に置き換えます。これにより、プロトコルを検証します。これにより、目的の効果が得られることを心配しません。
実際のサードパーティコードとのコード統合のテストについては、他の手法（視覚的検証、テクニカルサポートコール、楽観主義など）に依存しています。
サードパーティのライブラリをアップグレードするときに、想定がまだ維持されていることを確認できるように、いくつかのデモンストレーションアーティファクトを保持しておくと便利です。
ゴーストイメージはどのように見えますか？既知の1つの色のダミーUIを作成した場合、ドラッグ可能なコンポーネントをどこに配置しますか？ゴースト画像があった場合、特定の色が存在するでしょうか。
次に、ゴーストイメージの色の不在をテストできます。
そのようなテストは、合理的な耐久性と実行可能性があります。
別の見方をすれば、UI/GUIを中心としたテストは、受け入れテスト（機能/ビジネスワークフローを中心としたテスト）に関してはいくぶん優れています。
Webの場合、Selenium webdriverのようなフレームワークは正しいテストに近づく可能性があると思いますが、開始するためのオーバーヘッドは少し大きくなる可能性があり、単体テストのみに関してTDDで見られるフローの変化です。
状況に特に役立つ部分は、ページオブジェクトモデル（ https://www.guru99.com/page-object-model-pom-page-factory-in-Selenium-ultimate-guide。 html ）。これにより、メソッド/イベント/クラスメンバーに名前を付けることで、ランタイムGUIからコードへの明示的なマッピングが実現します。
これに対する主な議論はオーバーヘッドであり、このオーバーヘッドは通常、開発サイクルの終わりに見られます。オーバーヘッドは、テストが重複した作業を作成するように見えるいくつかのラッパーを必要とすることです。
今後は、チームとビジネスのコスト/メリットに依存するため、期待と見解を決定するために議論することは有益なトピックになる可能性があります。