修正された後にのみテストできるバグをTDDするにはどうすればよいですか？

次に例を示します。私の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アプローチはどうなりますか？コードの前にテストを書くことは必須ですか、それともオプションですか？

正しい動作を確認する唯一の方法は、画面を見てゴースト画像がないかどうかを確認することなので、ソリューションを見つけた後、「ゴースト画像」の例に対して信頼できる自動テストを書くことさえできません。もう。それはあなたの元の見出しが間違った質問をした印象を与えます。本当の質問は

• グラフィカルユーザーインターフェイスの特定の動作を自動的にテストする方法

答えは- いくつかの種類のUIの問題については、そうではありません。確かに、何らかの方法で問題を表示するUIを自動化し、スクリーンショット比較のようなものを実装しようとすることはできますが、これは多くの場合、エラーが発生しやすく、脆弱で費用対効果が高くありません。

特に、事前に作成された自動テストによる「テスト駆動」UIデザインまたはUIの改善は、文字通り不可能です。UIデザインを改善して「ドライブ」し、その結果を人間（自分、一部のテスター、またはユーザー）に見せて、フィードバックを求めます。

したがって、TDDは特効薬ではないという事実を受け入れてください。また、ある種の問題については、自動テストよりも手動テストの方が意味があります。専任のテスターがいる場合など、体系的なテストプロセスがある場合は、テスト計画にケースを追加するのが最善です。

この問題に対するTDDアプローチはどうなりますか？コードの前にテストを書くことは必須ですか、それともオプションですか？

1つの方法は、スパイクソリューションのアナログを適用することです。

ジェームズ・ショアは次のように説明しました：

詳細な情報が必要な場合は、小規模で隔離された実験を実行します。

基本的な考え方は、何が起こっているのかを考えながら、設計ツールを置くということです。ベアリングを入手したら、設計ツールを再度選択します。

秘:: 調査から得た知識を本番のコードベースに戻しますが、コードは持ち込みません。代わりに、規律のある設計手法を使用して、それを再作成します。

コース用の馬。

編集：

欠陥が人間の目にしか見えない場合、どのようにテストを自動化できますか？

「テストを自動化しても費用対効果が低い場合、どのようにテストを自動化できますか？」と少し違うスペルを提案したいと思います。

もちろん、答えは「しない」です。代わりに、実装を2つの部分に分割するようにしてください。テストの費用効果が大きい部分と、簡単すぎて壊れない部分です。

ソフトウェア設計を構築するには2つの方法があります：1つの方法は、それを明らかにシンプルにして欠陥がないようにすることです-CAR Hoare

そのため、サードパーティのコードを使用する場合、サードパーティのライブラリのプロキシとして機能する非常に薄いコードのシェルがあります。テストでは、そのシェルを「test double」に置き換えます。これにより、プロトコルを検証し、目的の効果が得られることを心配することはありません。

実際のサードパーティコードとのコード統合のテストでは、他の手法（視覚的検証、技術サポートの呼び出し、楽観主義など）に依存しています。

サードパーティのライブラリをアップグレードするときに仮定がまだ保持されていることを確認できるように、いくつかのデモンストレーションアーティファクトを保持しておくと便利です。

異なる観点からすれば、受け入れテスト（機能/ビジネスワークフロー中心のテスト）に関して、UI / GUIを中心にしたテストをやや改善することができます。

Webの場合、selenium webdriverのようなフレームワークは正しいテストに近づく可能性があると思いますが、開始するためのオーバーヘッドは少し大きくなる可能性があり、それは単体テストに関してTDDで見られるフローのシフトです。

状況に特に役立つ部分は、ページオブジェクトモデル（https://www.guru99.com/page-object-model-pom-page-factory-in-selenium-ultimate-guide.html）と呼ばれるものです。これにより、メソッド/イベント/クラスメンバの名前を指定することにより、ランタイムGUIをコードに明示的にマッピングできます。

これに対する主な議論はオーバーヘッドであり、このオーバーヘッドは通常、開発サイクルの終わりに見られる可能性があるということです。オーバーヘッドは、テストが重複した作業を作成するように見えるラッパーを必要とすることです。

今後は、チームとビジネスの費用/便益に依存するため、期待と意見を決定するために議論することが有益なトピックになる可能性があります。

ゴーストイメージはどのように見えますか？既知の色のダミーUIを作成した場合、ドラッグ可能なコンポーネントをどこに配置しますか？ゴーストイメージがある場合、特定の色が存在しますか。

次に、テストはゴーストイメージの色の不在をテストできます。

このようなテストは、妥当で耐久性があり実行可能です。