Guide des capacités

    Comment utiliser les ra:* capacités souhaitées de RobotActions — à la création de session, à l'exécution et via les API REST/WebSocket. Pour le tableau complet des capacités, consultez la Référence des capacités.

    1. Que sont les capacités ?

    Les capacités sont un objet JSON que vous envoyez à la grille lors de l'appel POST /session . Elles indiquent à la grille quelle plateforme vous souhaitez (Android, iOS, navigateur X), quel appareil/version, et quel comportement supplémentaire vous attendez de la session — enregistrement, profilage, nommage des tests, etc.

    La spécification W3C WebDriver définit un ensemble de base de capacités (platformName, browserName, browserVersion, …). Les pilotes ajoutent des capacités spécifiques au fournisseur sous leur propre espace de noms — Appium utilise appium:*, Selenium utilise se:*, et RobotActions utilise ra:*.

    json
    // Capabilities are a JSON payload you send when creating a WebDriver session.
    // The grid extracts ra:* values, strips them before forwarding to Appium /
    // Selenium, and uses them to opt into recording, profiling, suite grouping,
    // and so on.
    {
      "platformName": "Android",
      "appium:app": "path/to/app.apk",
      "appium:deviceName": "Google Pixel 8",
    
      // RobotActions namespace
      "ra:testName": "Login — happy path",
      "ra:videoRecording": true
    }

    2. L'espace de noms ra:*

    Chaque capacité RobotActions est préfixée par ra:. Trois raisons :

    • Conformité W3C — les capacités d'extension préfixées par le fournisseur sont la méthode prise en charge pour ajouter des comportements propriétaires sans rompre la conformité aux spécifications.
    • Sans conflit — n'entrera pas en conflit avec les futures capacités Appium ou Selenium, ni avec celles d'autres fournisseurs d'infonuagique.
    • Cycle de vie prévisible — le mandataire supprime ra:* avant de transmettre au Selenium Hub / serveur Appium, de sorte que les pilotes sous-jacents ne les voient jamais. Aucun risque de rejet de capacité non reconnue.
    Où les placer dans le corps JSON : Les clients W3C placent les capacités dans capabilities.alwaysMatch. Les clients JSON Wire legacy utilisent desiredCapabilities. Les deux fonctionnent ; la grille lit depuis l'un ou l'autre et depuis chaque entrée firstMatch[*] également.

    3. Définir les capacités à la création de session

    Transmettez les capacités ra:* de la même façon que toute autre capacité fournisseur — via le constructeur d'options/capacités de votre client. Trois exemples dans trois clients populaires :

    Selenium (Python)

    python
    from selenium import webdriver
    from selenium.webdriver.chrome.options import Options
    
    opts = Options()
    opts.set_capability("ra:testName", "Checkout — happy path")
    opts.set_capability("ra:testsuite", "regression-2026-05-15")
    opts.set_capability("ra:videoRecording", True)
    
    driver = webdriver.Remote(
        command_executor="https://<subdomain>.robotactions.com/t/<token>",
        options=opts,
    )

    Appium (Java)

    java
    UiAutomator2Options opts = new UiAutomator2Options()
        .setUdid("9B051FFBA007KA")
        .setAppPackage("com.myapp")
        .setAppActivity("com.myapp.MainActivity")
        .amend("ra:testName", "Login flow")
        .amend("ra:testsuite", "smoke-2026-05-16")
        .amend("ra:videoRecording", true)
        .amend("ra:appProfiling", true);   // CPU/memory/network samples — Android only
    
    AndroidDriver driver = new AndroidDriver(
        new URL("https://<subdomain>.robotactions.com/t/<token>"),
        opts);

    WebdriverIO (JavaScript)

    javascript
    const browser = await remote({
      protocol: "https",
      hostname: "<subdomain>.robotactions.com",
      path: "/t/<token>",
      port: 443,
      capabilities: {
        platformName: "Android",
        "appium:automationName": "uiautomator2",
        "appium:udid": "9B051FFBA007KA",
        "ra:testName": "Checkout regression",
        "ra:testsuite": "nightly-2026-05-16",
        "ra:videoRecording": true,
      },
    });

    4. Les définir à l'exécution

    Certaines capacités ne sont pas connues au moment de la création de session — le nom du test peut être dérivé de l'exécution du framework de test, le résultat n'est par définition connu qu'après l'exécution du test, le nom de la suite peut dépendre d'un identifiant de build CI injecté en cours d'exécution.

    Pour ces cas, RobotActions intercepte les chaînes magiques transmises à executeScript — avant que la chaîne n'atteigne le navigateur ou l'appareil sous-jacent — et les traite côté serveur. Fonctionne avec tout client de protocole WebDriver.

    python
    // Inside the test body — set pass/fail + naming from the test itself.
    // Works in any WebDriver-protocol client (Selenium, Appium, WebdriverIO).
    // The grid intercepts the magic string BEFORE it reaches the underlying
    // browser/device, so the test never sees an error if the verb is unknown.
    
    driver.execute_script("ra:job-name=Checkout — happy path")
    driver.execute_script("ra:testsuite=regression-2026-05-15")
    
    try:
        run_checkout_flow()
        driver.execute_script("ra:job-result=passed")
    except AssertionError as e:
        driver.execute_script(f"ra:job-result=failed:{e}")

    Verbes disponibles : ra:job-result=passed / ra:job-result=failed:<reason>, ra:job-name=<name>, ra:testsuite=<suite>, ra:fail-reason=<msg> (message uniquement, ne modifie pas le résultat), ra:profile-start / ra:profile-stop (profilage Android, contrôle à l'exécution).

    5. API REST et WebSocket de résultats

    La magie executeScript fonctionne pour les clients de protocole WebDriver. Pour Playwright — qui n'expose pas executeScript de la même façon — ou pour les scripts CI qui doivent écrire le résultat après la fin du processus de test, la grille expose un point de terminaison REST :

    bash
    # Set result + test name from outside the test (CI script, post-step hook, etc).
    # Works for any client — including Playwright where executeScript magic isn't available.
    
    curl -X POST "https://<subdomain>.robotactions.com:3001/api/sessions/$SESSION_ID/result" \
      -H "Authorization: Bearer $JWT" \
      -H "Content-Type: application/json" \
      -d '{
        "result": "failed",
        "message": "Login API returned 503",
        "test_name": "Auth — invalid creds",
        "test_suite": "smoke-2026-05-16"
      }'

    La même écriture est également disponible via WebSocket si votre client est déjà connecté au point de terminaison WS de la grille — envoyez { "type": "setSessionResult", "sessionId": "...", "result": "passed" | "failed", "message": "...", "testName": "..." } et la grille répond avec { "type": "sessionResultUpdated", "success": true }.

    Les quatre chemins (magie executeScript / REST / WS / liaison d'enregistrement Playwright) écrivent dans les mêmes colonnes sessions.result + sessions.result_message + sessions.test_name . Utilisez celui qui convient à votre client ; le tableau de bord, l'onglet Rapports et les récapitulatifs de suite les traitent de façon identique.

    6. Patrons courants

    Exécutions CI sans interface

    Lorsque le test s'exécute sans surveillance (régression nocturne, vérification PR), personne ne surveille la vue en direct du tableau de bord et l'inspecteur n'est pas connecté. Désactivez les flux en direct pour économiser le CPU et la bande passante, mais conservez l'enregistrement MP4 pour que les échecs puissent être analysés post-mortem.

    json
    // CI runs where the screen-mirror isn't needed — save CPU + bandwidth.
    {
      "platformName": "Android",
      "appium:app": "build/app-debug.apk",
      "appium:deviceName": "Pixel 8",
    
      "ra:liveView": false,       // disable the dashboard live-view button
      "ra:liveVideo": false,      // strip mjpeg* — no Inspector screen-mirror
      "ra:videoRecording": true,  // keep MP4 recording for post-run debugging
      "ra:autoFailDetect": true,  // default — let the grid mark failed if the last cmd 4xx'd
    
      "ra:testName": "${env.TEST_NAME}",
      "ra:testsuite": "ci-${env.BUILD_ID}"
    }

    Regroupement de tests pour les rapports

    Associez ra:testsuite avec ra:testName afin que l'onglet Rapports puisse afficher des cartes récapitulatives par suite (total des exécutions, réussies, échouées, non marquées).

    json
    // Surface a coherent build/suite view in the Reports tab.
    // ra:testsuite groups runs; ra:testName labels each leaf test.
    {
      "platformName": "Android",
      "appium:app": "build/app-debug.apk",
      "ra:testsuite": "regression-2026-05-15",   // shared across every test in the suite
      "ra:testName": "Settings — toggle dark mode"
    }

    Profilage d'application Android

    Ajoutez "ra:appProfiling": true à la création de session. Le plugin Appium échantillonne mobile:getPerformanceData toutes les ~3 s et écrit une ligne JSONL par tick (CPU utilisateur/noyau, mémoire totalPss, octets réseau rx/tx, puissance batterie). Disponible dans l'onglet Performances de la session sous forme de quatre graphiques linéaires SVG empilés avec corrélation au survol. Nécessite un appium:appPackage (ou un appium:appActivity préfixe) résolvable.

    Contrôle à l'exécution : driver.execute_script("ra:profile-start") / "ra:profile-stop". Idempotent.

    7. Tableau de référence

    Pour le tableau complet des capacités avec le type, la valeur par défaut, la portée et la fiche détaillée pour chaque capacité ra:* , consultez la page de référence dédiée.

    Ouvrir la référence des capacités

    👋 Bonjour! Besoin d'aide? Discutez avec nous!

    Discutez avec nous

    En ligne

    Avant de commencer

    Partagez vos coordonnées pour que nous puissions vous recontacter.