大規模なMFCUIアプリケーションをどのように単体テストしますか？
長年開発されてきた大規模なMFCアプリケーションがいくつかあります。いくつかの標準的な自動QAツールを使用して、基本的なスクリプトを実行し、ファンダメンタルズをチェックしたり、ファイルを開いたりします。これらは、デイリービルド後にQAグループによって実行されます。
ただし、個々の開発者がコードをデイリービルドに送信する前に、ダイアログ、メニュー、およびアプリケーションの他の視覚要素に対してテストをビルドして実行できるような手順を紹介したいと思います。
デバッグビルドでのみ表示されるダイアログの非表示のテストボタンなどの手法について聞いたことがありますが、このための標準的なツールキットはありますか。
環境は、C ++ / C / FORTRAN、MSVC 2005、Intel FORTRAN 9.1、Windows XP / Vista x86＆x64です。
MFCについておっしゃっていたので、自動テストハーネスの下で入手するのが難しいアプリケーションがあると思いました。コードを記述しながらテストを構築すると、単体テストフレームワークの最大の利点がわかります。ただし、テスト可能に設計されていないアプリケーションにテスト駆動方式で新しい機能を追加しようとすると、大変な作業になる可能性があります。そしてよくイライラします。
今私が提案しようとしているのは間違いなく大変な仕事です..しかし、ある程度の規律と忍耐力があれば、すぐにメリットがわかります。
簡単な方法は私の以前の答えでした。これは難しいですが、正しい方法です。
アプリの構造によって異なります。ロジックとGUIコードが分離されている場合（MVC）、ロジックのテストは簡単です。Michael Feathersの「HumbleDialogBox」（PDF）をご覧ください。
編集：あなたがそれについて考えるならば：アプリがそのように構造化されていない場合は、非常に注意深くリファクタリングする必要があります。ロジックをテストするための他の手法はありません。クリックをシミュレートするスクリプトは、表面を傷つけているだけです。
それは実際にはかなり簡単です：
ユーザーがボタンをクリックしたときにコントロール/ウィンドウ/リストボックスの内容を変更するものが何であれ、クリック後にリストボックスに適切なものが含まれていることを確認したいとします。
それでおしまい。コントローラにはロジックコードが含まれており、インターフェイスを介してのみ制御を認識します。これで、コントロールをモックすることで、MyController :: ButtonWasClicked（）の通常の単体テストを記述できます。私が何について話しているのかわからない場合は、Michaelsの記事を読んでください。2回。そしてまたその後。
（自己への注意：それほど吹き飛ばさないことを学ばなければなりません）
完璧ではありませんが、これについて私が見つけた最高のものは AutoIt http://www.autoitscript.com/autoit3です
「AutoIt v3 は、Windows GUI と一般的なスクリプトを自動化するために設計された、フリーウェアの BASIC に似たスクリプト言語です。シミュレートされたキーストローク、マウスの動き、およびウィンドウ/コントロール操作の組み合わせを使用して、他の方法では不可能または信頼できない方法でタスクを自動化します。また、AutoIt は非常に小さく、自己完結型であり、煩わしい「ランタイム」を必要とせずに、箱から出してすぐに Windows のすべてのバージョンで実行できます!"
これは、駆動するコントロールのリソース ID 番号を使用できるため、駆動されるアプリケーションのソース コードにアクセスできる場合にうまく機能します。このようにして、特定のピクセルでのシミュレートされたマウス クリックについて心配する必要はありません。残念ながら、レガシ アプリケーションでは、リソース ID が一意ではなく、問題が発生する可能性があります。でも。ID を一意に変更して再構築するのは非常に簡単です。
もう 1 つの問題は、タイミングの問題が発生することです。私は、これらに対する実証済みの真の解決策を持っていません。試行錯誤は私が使用したものですが、これは明らかにスケーラブルではありません。問題は、スクリプトが次のコマンドを発行したり、正しい応答を確認したりする前に、AutoIT スクリプトがテスト アプリケーションがコマンドに応答するのを待たなければならないことです。待機して監視するのに便利なイベントを見つけるのは簡単ではない場合があります。
私の感覚では、新しいアプリケーションを開発する際に、一貫した方法で「READY」を知らせることを主張したいと思います。これは、人間のユーザーだけでなく、テスト スクリプトにも役立ちます。これはレガシーアプリの課題かもしれませんが、問題点に導入し、メンテナンスを重ねながらゆっくりとアプリ全体に広げていくことができるのではないでしょうか。
UI 側は扱えませんが、Boost Test ライブラリを使って MFC コードの単体テストを行っています。開始に関する Code Project の記事があります。
職場には、これらの巨大なMFCアプリの1つがあります。維持したり伸ばしたりするのは非常に苦痛です...今は大きな泥だんごですが、ムーラをかき集めます。とにかく
ある程度の成功を収めたもう1つのアプローチは、VBScriptといくつかのControlハンドルスパイマジックを使用する小さな製品固有の言語とスクリプトテストを作成することです。一般的なアクションをコマンドに変換します。たとえば、OpenDatabaseは、必要なスクリプトブロックを挿入して、[メインメニュー]>[ファイル]>[開く...]をクリックするコマンドになります。次に、そのような一連のコマンドであるExcelシートを作成します。これらのコマンドもパラメータを取ることができます。FITテストのようなものですが、もっと作業が必要です。一般的なコマンドのほとんどを特定し、スクリプトを準備したら。新しいテストを作成するために、スクリプト（CommandIDでタグ付けされたもの）を選択してアセンブルします。テストランナーはこれらのExcelシートを解析し、すべての小さなスクリプトブロックをテストスクリプトに結合して実行します。
HTH
実際には、Rational Team Test、次に Robot を使用してきましたが、Rational との最近の話し合いで、Rational が .NET に重点を置いたネイティブ x64 アプリケーションをサポートする計画がないことを発見したため、自動 QA ツールに切り替えることにしました。これは素晴らしいことですが、ライセンス コストの関係で、すべての開発者に対して有効にすることはできません。
私たちのすべてのアプリケーションはスクリプト用の COM API をサポートしており、VB を介して回帰テストを行いますが、これはアプリケーション自体ではなく API をテストします。
理想的には、cppunit や同様の単体テスト フレームワークを開発者レベルでアプリケーションに統合する方法に興味があります。