Simulateurs partagés : paralléliser sans mélanger les sessions

Multiplier les simulateurs iOS ne suffit pas à augmenter le débit des tests. Les sessions partagent des ressources de machine et peuvent aussi partager, par accident, les données du backend. Leur isolation devient une partie du workflow mobile.

Un outil pour agir sur l’application

MobAI (nouvelle fenêtre) présente un accès aux simulateurs et aux téléphones permettant de lire l’interface, effectuer des gestes et collecter des preuves d’exécution. Le produit propose aussi des parcours et une intégration CI.

Le bénéfice potentiel est de vérifier le comportement de l’app au moment où le code change. Mais partager un appareil ne revient pas à partager un fichier : l’écran courant, le compte connecté et les permissions sont un état mutable commun.

Isoler avant de lancer en parallèle

Définir un propriétaire par session évite qu’un test de recherche ferme la modale ouverte par un test de paiement. L’isolation doit aussi couvrir les données : deux simulateurs distincts utilisant le même compte peuvent encore se perturber via le serveur.

Une première expérimentation peut se limiter à deux parcours indépendants. Vérifier qu’ils disposent chacun d’un build identifié, d’un compte de test et d’un état de départ. Rejouer ensuite les mêmes parcours en série permet de voir si la parallélisation a changé les échecs.

Mesurer la capacité utile

Le nombre maximal de simulateurs démarrés ne dit pas combien de tests l’équipe peut faire terminer de manière fiable. Temps de boot, installation, saturation CPU, mémoire et nettoyage après échec comptent dans le débit réel.

Conserver une limite de concurrence et un moyen de récupérer une session abandonnée est plus utile qu’une promesse de parallélisme illimité.