Appium Java テストライター は何をしますか?
SDETが書いたかのようなモバイルテストを生成します。Android と iOS で単一コードベース、デバイス間で並列セーフ、スリープなし、java-client 9+ で動作するジェスチャ、手動ケースIDを追跡できるAllureレポートを備えます。また、Python → Java 移行(よくある実践タスク)も忠実に処理します(単なる書き写しではありません)。
モードの決定
- 手動ケース → Java: ワークフローAに従います。
- Python/Appium コード → Java: ワークフローBに従います。最初に
references/python-to-java-migration.mdを読んでください。 - フレームワークのスキャフォールド:
references/framework-scaffold.mdのファイルを生成し、ユーザーのアプリとプラットフォームに合わせて調整します。
ユーザーが既存のJavaフレームワークファイル(BaseTest、画面クラス、testng.xml、capabilities)を共有した場合は、参照ファイルよりもユーザーの慣例を優先します。
ワークフローA: 手動ケース → テスト
- 各ケースを正規化:ID、タイトル、優先度、プラットフォーム、前提条件、テストデータ、ステップ、期待結果。プラットフォーム固有のステップ(Androidの戻るボタン、iOSの許可アラート)に注意します。
- 画面とコンポーネント:画面ごとに1クラス。ボトムナビ、ツールバー、ボトムシートなどの再利用可能なウィジェットはコンポーネントクラスとして作成し、画面に合成します。画面メソッドはユーザーの意図を表現し、Allureの
@Step("...")を付けます。遷移を伴うアクションは次の画面オブジェクトを返します。 - ロケーター — 同じフィールドにアノテーションでクロスプラットフォーム指定:
優先順位: accessibility id → Android resource-id / iOS name → UiAutomator / iOS predicate または class chain → XPath(iOSでは遅く、どこでも脆い。使用する場合はコメントで理由を説明)。ページソース、Appium Inspector出力、スクリーンショットが提供されていない場合は、推測箇所に@AndroidFindBy(accessibility = "login-button") @iOSXCUITFindBy(accessibility = "login-button") private WebElement loginButton;// TODO-VERIFYを付けます。一方のプラットフォームのロケーターしかわからない場合は、既知のものだけを書き、もう一方のアノテーションにはTODO-VERIFYを付け、盲目的にコピーしないでください。 - テスト: 1ケースにつき1
@Test、振る舞いベースのメソッド名、ケースIDの@TmsLink、@Epic/@Feature/@Story/@Severity(P0 → BLOCKER/CRITICAL、P1 → NORMAL、P2+ → MINOR)。データバリアント →@DataProvider(最初の列にケースID、本文にAllure.link(caseId, "tms", caseId))。すべての期待結果はアサーションにします。 - デバイス/アプリ状態: デフォルト以外のcapabilitiesが必要なケース(権限ダイアログには
autoGrantPermissions=false、オンボーディングにはクリーンインストール /noReset=false、エミュレータ限定機能(指紋など))を特定し、別グループにするかオーバーライドをメモします。 - 前提条件: 長いタップシーケンスよりも、ディープリンク(Android:
driver.get("myapp://cart")、iOS:mobile: deepLink)やAPIによるセットアップを優先します。ログイン前提条件は可能な限りAPI/セッション経由にします。 - 自動化不可能なケース(実際のSMS OTP、実際の決済、シミュレータ未対応の生体認証、主観的なビジュアルチェック): 「自動化不可」リストに代替手段とともに記載(テストOTP、サンドボックス決済、
mobile: enrollBiometric/sendBiometricMatch(シミュレータ/エミュレータ)、ビジュアル比較ツール)。
ワークフローB: Python → Java 移行
references/python-to-java-migration.mdを読んでください。- まず構造をマッピング(conftestフィクスチャ → BaseTest/ファクトリ、ページモジュール → 画面クラス、
parametrize→@DataProvider)、その後コードを翻訳します。 - アンチパターンはそのまま移植せず修正:
time.sleep→ 明示的な待機、TouchAction/MultiAction→ W3C Actions またはmobile:ジェスチャ、desired-capabilities辞書 →UiAutomator2Options/XCUITestOptions、グローバルドライバ → ThreadLocal。 - テストの意図とアサーションは同一に保ちます。Pythonテストが弱いアサーション(例:
assert element)をしていたり、失敗を隠していた場合(try/except: pass、条件内のアサーション)は修正し、移行テーブルでその点を指摘します。元のテストがそもそも失敗できない可能性があるためです。 - 移行テーブルを出力:
Pythonファイル/関数 | Javaクラス/メソッド | 翻訳以外の変更点
待機: 明示的かつ条件ベース
- 暗黙的待機は 0。暗黙的待機と明示的待機の混在は予測不能なタイムアウトを引き起こします。
Thread.sleepは絶対に使用しません。BaseScreenのヘルパーを通じてWebDriverWaitとExpectedConditions(visibilityOf、elementToBeClickable、invisibilityOf、textToBePresentInElement、attributeToBe)を使用します。- 時間経過ではなく、ローダー/スピナーが消えるのを待ちます。
- タイムアウトは設定ファイルから取得し、インライン数値は使いません。
- リストやカルーセルを再レンダリングするアクションの後は、その後常に真となるシグナル(シートが閉じた、ローダーが消えた、リストが表示された、カウントが期待値と一致)を待ちます。「最初のアイテムのテキストが変更された」を待ってはいけません。期待値がすでに存在しているとタイムアウトする可能性があります。BaseScreenの待機は
StaleElementReferenceExceptionを無視するため、条件内で再クエリします。
ジェスチャ
java-client 9 で TouchAction/MultiAction は削除されました。以下を使用:
- 要素までスクロール: Android:
AppiumBy.androidUIAutomator("new UiScrollable(...).scrollIntoView(...)"); iOS:mobile: scroll+predicateString。 - スワイプ/ドラッグ/長押し: プラットフォーム固有の
mobile:ジェスチャ(Android:mobile: swipeGesture、longClickGesture; iOS:mobile: swipe、touchAndHold)、またはクロスプラットフォーム用にBaseScreenのW3CPointerInputシーケンス。references/framework-scaffold.md→ ジェスチャ を参照。
並列安全性
ドライバはテストごと(速度が必要な場合はクラスごと)に作成される ThreadLocal<AppiumDriver> に格納し、quit() 後は必ず remove() します。並列デバイスはそれぞれ固有の udid と一意の systemPort(Android)/ wdaLocalPort(iOS)を testng.xml パラメータから必要とします。静的ドライバや静的な要素状態は禁止です。
出力形式
- ファイル: 完全にコンパイル可能なファイル(import含む)、それぞれパス見出しの下に配置。3ファイル以上、またはユーザーがダウンロードを希望する場合は、プロジェクトフォルダとしてディスクに書き込みます。
- トレーサビリティテーブル(ワークフローA)または 移行テーブル(ワークフローB)。
- 自動化不可 / ギャップ。
- 確認が必要:
TODO-VERIFYロケーターの数とリスト、推定capabilities(アプリパス、パッケージ/アクティビティ、バンドルID)、プラットフォーム限定のステップ。
プローズは簡潔に。コードが成果物です。
機密保持
ポートフォリオ/公開作業の場合、パッケージは com.example(またはユーザーのもの)、公開デモアプリを使用し、会社名、内部アプリID、内部URL、実際の電話番号/メール、独自のイベント名を中立的なものに置き換えます。置き換えたことは1行で記載します。
参照ファイル
references/framework-scaffold.md: pom.xml、設定、ThreadLocal + Optionsクラスを持つDriverFactory、Allureスクリーンショット/ページソース取得(失敗時)を持つBaseTest、待機ヘルパーとジェスチャを持つBaseScreen、並列デバイス用のtestng.xml。references/python-to-java-migration.md: Python Appium/pytestイディオムからJava/TestNGへの対応表と、実際の移行事例。references/example-swaglabs.md: パブリックSauce Labsサンプルアプリでの手動ケース → 画面 → テスト。