C'est compliqué.
J'ai eu l'occasion de mettre ça en place avec un serveur d'intégration jenkins + xcodebuild "classique". Quelques écueils :
* le simulateur n'est pas applescriptable, encore moins avec automator.
* il n'y a pas d'api officielle pour lancer le simulateur depuis la ligne de commande.
WaxSim et
iOS-Sim utilisent des apis privées.
* il est rigoureusement impossible de lancer plusieurs instances du simulateur en parallèle sur le même mac. (Même dans des sessions utilisateurs séparées).
* pour les tests d'intégration à proprement parler, il y a plusieurs frameworks, mais aucun n'est vraiment satisfaisant :
* UIAutomation, le truc d'Apple en javascript était vraiment trop limité la dernière fois que j'ai regardé, et impossible à driver depuis une ligne de commande. (Ça ne marche qu'avec Instruments)
*
Frank (pas essayé) m'a l'air un peu lourdingue, et demande d'écrire les tests séparément, au format cucumber.
*
KIF, que j'utilise, permet d'écrire les tests en objective-C et donc s'intègre plus simplement de ce côté; par contre, l'api est *déroutante*, et les tests sont difficiles à débugguer.
Bref, c'est possible, et au final ça marche, mais ça reste assez frustrant. Mieux vaut être déjà à l'aise avec xcodebuild et un serveur d'intégration.
Plus généralement, je suis assez dérouté devant ces outils : j'ai l'impression qu'il s'agit de technos de rubyistes adaptées telles-quelles pour iOS (on teste une appli native et pas un site web, pour commencer). Si je voulais faire des tests de haut niveau sur une appli mac, justement, j'utiliserais Applescript ou Automator. On est très très loin de ça.
Si quelqu'un a un avis un peu plus général sur la "bonne façon" de faire des tests d'interface, ça m'intéresse assez.
(Sans jugement de valeur sur les rubyistes. :D)
(Je suis parti du principe que tu n'avais pas encore écrit tes tests, mais ton mail reste flou sur le sujet. Tu as déjà une solution qui tourne en local ?)
--
Nicolas