ユニットテストの作成は、ソフトウェア開発の中でも最も時間がかかり、創造性を必要としない工程の一つです。開発者がひとつのQMLコンポーネントを書くたびに、同量のテストコードが必要になります。プロパティ、シグナル、マウス・キー操作、状態遷移、エッジケースなど、あらゆる側面をカバーしなければなりません。
実際のところ、網羅的なテストスイートを作成するには、プロダクションコードの作成と同じくらいの時間がかかることもあります。しかも求められるのは創造性ではなく正確性です。同じ定型構造が際限なく繰り返され、ひとつの記述漏れや誤った親要素の参照が、テスト全体を静かに無効化してしまいます。
Qt の AI駆動開発ツールへ価値ある追加として、Qt Quick Test スキルはこの作業の自動化を支援します。エージェントは1つ以上のQMLソースファイルを受け取り、すぐに実行できる tst_*.qml テストファイルを生成し、必要に応じてビルドシステムへの組み込みも行い、テストを実行して、構造化されたMarkdownレポートを出力します。開発者はテストの定型コードを一行も書く必要がありません。
このテストスキルのコンセプトはシンプルです：生成されるテストは厳格な標準テンプレートと47の確定的ルールに従います。付属のランナースキルは、開発者がフラグで明示的に許可しない限り、プロジェクトを変更することなくテストを実行します。
動画：Claude Code での Qt Quick Test スキル（一部シーケンスは短縮・加速）
qt-qml-test スキルはテスト作成を担当します。QMLソースファイルを読み込み、トップレベルの型を分類し、正しいインポートパスを解決した上で、Qt Quick Test のプリミティブ（TestCase、SignalSpy、tryCompare、マウス・キーイベントヘルパー全種）を使って tst_*.qml ファイルを生成します。qt-qml-test-run スキルは実行を担当します。Qtのインストール先を特定し、CMakeのテスト組み込みが存在するかを確認し、プロジェクトをビルドし、qmltestrunner またはコンパイル済みテストバイナリを実行し、JUnit XMLの出力をパースして、Markdownレポートを書き出します。2つのスキルは順番に使用する設計です（先に作成、次に実行）が、それぞれ単独でも呼び出せます。
qt-qml-test スキルは、開発者がQMLファイルのテスト作成、Qt Quick Testの生成、特定コンポーネントのプロパティやシグナルのカバレッジ追加を求めたときに起動します。「write tests for MyButton.qml」「qml test」「cover all signals in this component」といったフレーズで起動できます。qt-qml-test-run スキルは「run my qml tests」「execute the qmltestrunner」などの指示で、または qt-qml-test が新しいテストファイルを生成した直後に自動的に起動します。どちらのスキルも対象範囲を柔軟に設定でき、1ファイル、ディレクトリ、またはプロジェクト全体を1回の呼び出しで対象にできます。
スキルが起動すると、開発者が手動で行う必要があった一連の作業を引き受けます。具体的には、Qt Quick Testのドキュメントの確認、標準構造の決定、インポートパスの解決、コントロールごとの細かな対応、そしてテストを実行する前のビルドシステムの設定です。各ステップの詳細を以下に説明します。
スキルはQMLソースファイルを読み込み、トップレベルの型を分類して適切なテンプレートを選択します。
スキルは、テスト対象のコンポーネントをテストファイルから参照できるようにするインポート行を解決します。最も近い CMakeLists.txt を読み込み、qt_add_qml_module の URI 宣言のみを検索します。
標準テンプレートは、Component と TestCase を外側の Item { id: root } で囲む構造です。スキルは以下の項目を網羅した47の確定的ルールを適用します。
QtQuick と QtTest のインポート。テストが Controls の型を名前で参照する場合は QtQuick.Controls を追加。anchors や currentIndex はスキップ。width と height を指定。id のみで objectName を持たない内部アイテムについては、objectName 宣言の追加とカバレッジの拡張を提案。compare または tryCompare）で終わる必要があります。存在確認だけではテスト本体として不十分です。画像：GitHub Copilot で Qt の Thermostat デモアプリケーションに Qt Quick Test スキルを使用した画面
実行の前に、ランナースキルは CMakeLists.txt ファイルを検索して QUICK_TEST_MAIN、qt_add_test などのパターンを確認し、CMakeのテスト組み込みが存在するかを判定します。2つ以上のパターンが一致した場合は既存のハーネスを直接使用します。一致するパターンが2つ未満の場合は、tests ディレクトリに対して qmltestrunner を直接呼び出すモードにフォールバックします。ファイルへの変更はなく、相対インポートを使用する任意の tst_*.qml で動作します。
実行モードが決定すると、スキルはCMakeでプロジェクトをビルドし（--no-build を指定しない場合）、テストバイナリまたは qmltestrunner を -o <report.xml>,junitxml で実行し、付属のPythonスクリプトでJUnit XMLをパースします。
パース結果（合計・合格・失敗・スキップ数、実行時間、最も遅い10テストケース、失敗メッセージ）は、タイムスタンプ付きのファイル名で tests/reports/ 以下に構造化されたMarkdownレポートとして書き出されます。コンソールには判定行と最初の3件の失敗が表示されます。前回の実行以降にソースファイルが変更されている場合は、プレフィックス行でその旨を示し、差分を先に確認するよう促します。
画像：Claude Code での Qt Quick Test Run スキルの結果画面
生成されるテストケースの数は、使用するフロンティアモデルとその設定に依存します。最大の労力設定で大規模かつプロパティ数の多いコンポーネントを処理すれば、網羅的なスイートが生成されます。一方、設定が低かったり、コンテキストウィンドウが小さい場合は、主要なシグナルとプロパティが優先されます。生成された結果は確かな出発点として扱い、アプリケーションの実行時の振る舞いに関する知識が必要なドメイン固有の不変条件やエラーパスについては、レビュー担当者が追加のテストケースを補う必要があります。
GitHub Copilot（GPT 5.4バックエンド）などのエージェント環境では、多数のQMLドキュメントを含む大規模プロジェクト全体に対してスキルを呼び出した場合、定型的なテストケースしか生成されないことがあります。この場合、エージェントのコンテキストが全ソースに分散され、個々のコンポーネントへの分析が浅くなり、オブジェクトのインスタンス化確認程度の薄いテスト本体しか生成されません。大規模プロジェクトで十分なカバレッジを得るには、プロジェクトディレクトリ全体を一度に対象とするのではなく、QMLファイルごとに個別にスキルを起動することをお勧めします。
これらのスキルはQt 6向けのQMLテストケースに特化しており、C++ QtTest、Squish GUIテスト自動化、qmakeベースのビルドシステム、クロスコンパイルされたデバイス上でのテスト実行はサポートしていません。
生成されるテストには、ジェネレーティブAIによるユニットテスト作成に共通の特性があります。カバレッジはソースファイルで宣言された公開APIに基づくものであり、内部の実装パスや実行時のデータフローには依存しません。外部状態、ネットワークリソース、またはQMLソースから参照できないC++バックエンドオブジェクトに依存するテストは対象外となります。また、State/PropertyChanges ブロックで設定されるプロパティについては、スキルが状態の制御方法を正しく推論できない場合があります。
Qt Quick 3Dのグラフィカルノードソース（Model、Node、カメラ型、ライト型、Skybox、SceneEnvironment）は設計上スキップされます。これらを標準テンプレートの Item { id: root } で囲むと、テストはPASSと報告される一方で実行時警告が発生し、レンダリングのインタラクションはテストされないままになります。View3D をルートとするソースおよびQt Quick 3Dマテリアルはサポートされており、標準テンプレートを使用します。
ランナースキルは完全なCIインフラの代替ではありません。ローカルでの単一実行のテスト結果を生成・パースするものであり、テストの並列化、カバレッジ収集、マルチプラットフォームのマトリックス実行には対応していません。アーキテクチャレベルの品質管理と静的解析は、QtコードレビュースキルとAxivionなどの専用ツールの領域です。
Claude Desktopなど一部のツールでは、サンドボックス環境の制約上、エージェンティックワークフロー内でテストを実行できません。この場合、生成されたテストはユーザーが手動で実行する必要があります。
qt-qml-test スキルに必要なのは、エージェントのファイル書き込み機能のみです。qt-qml-test-run スキルには、PATH または $QT_HOST_PATH/bin/ 配下に qmltestrunner が含まれるQt 6のインストール、付属のJUnit XMLパーサー用のPython 3、CMake組み込みを使用するプロジェクト向けのCMake、および実行間の差分レポート機能を使用する場合はGitが必要です。標準ライブラリ以外のPythonパッケージは不要です。
このスキルは、Claude Code CLI、Claude Desktop（Coworkモード）、Qt Creator 20、VS Code上のGitHub Copilotでテストされています。Claude Sonnet 4.6、GPT 5.4、Gemini 3.1 Proは良好な結果を出しています。これらのテスト済み構成以外では、詳細なタスクには常にフロンティアモデルの使用を推奨します。
Qtエージェントスキルは、GitHubリポジトリから入手できます：https://github.com/TheQtCompanyRnD/agent-skills
また、qt-developmentプラグイン（「qt-development」で検索）の一部として、ClaudeのマーケットプレイスからQt Quick Testスキルを直接インストールすることもできます。すでにプラグインをインストール済みのユーザーは、Claudeにプラグインのアップグレードを依頼することで、新しいスキルをすぐに取得できます。