コード化されたUIテストを使用してDelphiアプリケーションをテストしたいのですが、いくつか問題があります。UIの一部の要素にアクセスしたいのですが、すべての要素にアクセスできません。
画面にいくつかの行（検索パラメーターによる）のリストがあり、これらの行にアクセスして値の整合性を確認したいと思います。しかし、Coded UI Test Builderのクロスでは、アプリケーションの行にアクセスできません。行にアクセスするにはどうすればよいですか？
今のところ1つの解決策を見つけました。MicrosoftWebサイトのサンプルのように、Delphiアプリケーションと適切に対話するためのコード化されたUIテストの拡張機能を開発します。これは、各セルにアクセスできるようにするExcelの拡張機能です。しかし、それは難しいように聞こえ、私がテストしなければならないアプリケーションも本当に複雑です。
インターフェースがプレーンな VCL の場合、ほとんどのコンポーネントにその下のHWNDハンドルを使用してアクセスできます。それはうまくいくでしょうTEdit TMemo TComboBox TCheckBox。ただし、一部のグラフィック コンポーネントは、GDI メッセージからアクセスできません。たとえばTLabel、 やTGrid.
したがって、VCL コンポーネント レベルにアクセスできるようにするには、アプリケーションで Delphi プラグインを使用する必要があると思います。(再帰呼び出しを介して)のComponentCount + Components[]プロパティを使用して、テスト対象のコンポーネントにアクセスします。TForm次に、そのプロパティをコード化された UI テストの拡張機能に公開します。これは作成される予定です。
ここで「プラグイン」について話すのは、監視/変更するすべてのクラスに簡単にアクセスできるとは思わないからです。一部の「プラグイン」アーキテクチャは、テスト フェーズ中に、アプリケーションが通常どおり、または「コード化された UI テスト モード」で動作するのに役立つ場合があります。おそらく、テスト目的で個別にコンパイルするよりも良いでしょう。最終的にコンパイルされた実行可能ファイルをテストする方が良いでしょう。単体テストのみが必要な場合は、アプリケーションを再コンパイル、スタブ、およびモックして、特定のフォームのみをテストできます。ただし、(依存性注入などを使用して) 簡単に単体テストできるようにフォームをコーディングする必要があります。これは、デフォルトの Delphi の世界では (他の RAD アプローチと同様に) 簡単ではありません。
そのようなプラットフォームを開発するためにオープン ソース プロジェクト (DUnit に含まれていますか?) を開始するのは興味深いことです。または、Delphi の既存の UI テスト フレームワークをベースとして使用します。私たちが働いている多くの企業は、.Net と Delphi テクノロジを混在させており、そのようなツールがあればメリットがあります。