Sharding déterministe
Un run d'instrumentation se découpe par classes (`extra.class`), pas à l'aveugle : chaque shard sait exactement quelles classes il exécute. L'agrégation repère les tests exécutés deux fois et ceux qui n'ont jamais tourné.
Vous poussez vos APK, Essaim répartit la suite sur plusieurs appareils réels et agrège les résultats JUnit. Chaque appareil rend son verdict, ses journaux et ses captures : le shard qui échoue est identifié, pas deviné.
Sans carte bancaire pour commencer. Paiement sécurisé par Stripe quand vous changez d'offre.
Trois shards en parallèle, un seul résultat JUnit.
Un run d'instrumentation se découpe par classes (`extra.class`), pas à l'aveugle : chaque shard sait exactement quelles classes il exécute. L'agrégation repère les tests exécutés deux fois et ceux qui n'ont jamais tourné.
Essaim relit le JUnit XML de chaque appareil, calcule les totaux et détaille les échecs. Le code de sortie est 0 si tout est vert, 1 sinon — dans votre CI, il bloque la fusion.
L'unité de compte est la minute d'appareil. Le coût d'un run est calculé avant de le lancer, un minimum est réservé à la création, et le débit réel est ajusté à la fin.
`POST /api/v1/runs`, la CLI `essaim run --app app.apk --test app-test.apk --devices pixel,samsung-a`, et un webhook `run.completed` signé HMAC (X-Hangar-Signature).
Essaim ne stocke aucun octet : le dépôt est relayé à Hangar, et le client ne parle qu'à Essaim grâce à une URL signée qui lui appartient. Les artefacts sont servis de la même façon.
Chaque appareil rend son JUnit XML. Essaim les relit, additionne, et repère ce qu'une addition naïve laisse passer : un test exécuté deux fois, un test qui n'a jamais tourné.
| Shard | Appareil | Classes | Tests | Échecs | Durée |
|---|---|---|---|---|---|
| 1 | Redmi Note 13 | LoginTest, CartTest | 14 | 0 | 1 min 12 |
| 2 | SM-X110 (tablette) | SearchTest, ProfileTest | 14 | 0 | 58 s |
| 3 | autre appareil | CheckoutTest, SettingsTest | 14 | 0 | 1 min 03 |
| Agrégé | 6 classes | 42 | 0 | 2 min 04 | |
exécutés deux fois : 0 · jamais exécutés : 0 · exit 0
Le code de sortie est 0 si tout est vert, 1 sinon : dans votre CI, c'est lui qui bloque la fusion.
Un produit qui cache ses limites fait perdre du temps à tout le monde. Voici les nôtres, aujourd'hui.
Non : le socle lance `am instrument <paquet>/<runner>` et Essaim ne lit pas les APK. Sans `test_package`, la requête est refusée en 400.
Pas aujourd'hui. Côté socle, seul un job `capture` enregistre l'écran : le paramètre `record_video` d'un job `flow` est accepté mais ignoré. Les preuves livrées sont `junit.xml`, `tests.json`, `instrument.log` et `logcat.txt` pour l'instrumentation ; `report.xml`, `steps.json`, `maestro.log` et les captures pour les flows.
Au maximum 120 secondes. Au-delà, la réponse est 202 et il faut interroger le run — ou écouter le webhook `run.completed`.
Pas en phase 1. Le sélecteur vise un modèle ou une version d'Android, mais la matrice multi-modèles et le robot d'exploration (`monkey` sans nom de paquet) ne sont pas faits : le socle exige le paquet, qu'Essaim ne sait pas lire dans un APK.
Créez un compte, prenez une clé, lancez votre premier test. C'est gratuit pour commencer.