J'ai plusieurs tests d'interface utilisateur. Quand j'exécute un seul test, tout va bien. Mais si j'exécute un lot d'entre eux (dans le cadre de la construction CI) échoue, car les tests qui vont d'abord modifier l'état de l'application et les prochains essai sont affectés par ces changements. (Étant donné que l'application ne se fait pas tuer).
J'ai essayé Y a-t-il un moyen d'avoir une application fraîche au début de chaque essai? (Utilisation du robotium). getactivity (). Terminer () dans dératrement () .
Essayé solo.finalize () qui fait la même chose.
Et existe-t-il un moyen de tuer par programme l'application à la fin d'un test?
J'utilise ActivityStrumentationTestCase2 avec RoboTium
7 Réponses :
Si vous exécutez votre construction avec Maven ou ANT (Robotium est une enveloppe de commodité pour les tests Junit), il est possible de rechercher un nouveau processus pour chaque classe de test ou même cas de test. Ceci fournit un environnement propre, mais ralentit l'exécution des tests.
Je préfère personnellement coller avec la vanille Junit / Testng et utiliser la moquure (avec Jmockit) pour assurer une interaction appropriée entre mon code et mon Android. Voir l'exemple ici:
En fait, il faut utiliser l'instrument ADB Shell AM pour exécuter des tests sur Android et non Junit. Il ne semble pas être de toute façon des processus de fourchettes pour chaque test via adb
Pourquoi ne pas ajouter de manière adhoc de "tuer" l'application, en fonction de l'application spécifique que vous testez?
Par exemple, en fonction de la profondeur d'activité de votre application, "appuyez sur 3 fois" ou quelque chose de similaire pourrait être assez bon.
Vous pouvez ajouter que dans la méthode TeReLowdown de votre superclasse Tests, de sorte qu'il a couru après chacun de vos tests.
Vous devriez penser à votre robotium tests
Je vais essayer cela dès que possible et vous donner des commentaires.
Unité Test Runner se bloque simplement lorsque l'application sous Test STOPS [ECHO] Test Package: Story.Album [EXEC] [EXEC] [EXEC] Story.album.album1Story: [Exec] Instrumentation_Result: ShortMSG = Processus s'est écrasé. [Exec] Instrumentation_code: 0
Je l'ai fait. Nécessaire de mettre à jour beaucoup de tests. Mais fonctionne bien. Un inconvénient - Si des tests changent, vous devez vous assurer que ce code "nettoyer" est également mis à jour.
Les causes du problème sont les suivantes:
Robotium utilise la solution de contournement, mais il établit son activité d'activité après votre analyse d'activitéStrumentationTestCase2 commence son activité, c'est-à-dire.:
Si votre activité-sous-test est une activité de transfert, il s'agit probablement de démarrer l'activité de destination avant que Solo enregistre son activité d'activité. Solo.FinishopédopédopEcédicessAcédities () repose sur la liste qu'elle collectée à partir de son activité d'activité. Selon le @guillaume Réponse < / a>, j'appelle cette méthode à partir du boîtier de test ou de la déchirure ():
ou simplement ajouter solo.finishopédopédopédopédopédopédopédopédopédopes ();
Pas vraiment sûr de la nature de votre suite de tests, mais j'avais des problèmes à exécuter de multiples tests «de départ frais» et à accrocher au deuxième test. Mon problème lié aux activités engendrées et a été sévéré en lançant l'activité avec Flag_activity_clear_top - bien sûr, cela efface la pile, mais je pense que c'est ce que vous voulez?
Cela m'a fait pour moi, merci! De plus, et puisque j'ai une boîte de dialogue de confirmation pour quitter mon application Solo.FinishopédicaNishopédities () ne le fera pas, devez utiliser solo.goback () et appuyez sur le bouton approprié dans la boîte de dialogue.
Vous pouvez essayer de supprimer Super.tardown ();
Ma solution:
@Override
public void tearDown() throws Exception {
solo.finishOpenedActivities();
super.tearDown();
}
Cela pourrait bien ralentir vos tests un peu. Avez-vous essayé de réinitialiser votre candidature à un état connu comme une sorte de processus de configuration plutôt que de le tuer réellement et de la réinitialiser?
Les propriétés (une partie de l'état d'application) de l'application que mon test affecté par sont initialisées au démarrage. Donc, il n'y a aucun moyen que je puisse faire cela sans changer la manière dont l'application fonctionne. Il me demande que tout le concept de test consiste à avoir des courses isolées, Buttin Android Test de cet isolement est compromis, au moins de l'interface utilisateur. Je pense que cela devrait être considéré comme un problème fondamental, mais je ne peux pas sembler trouver des informations sur ce problème.
Je suis d'accord. J'ai exactement le même problème: les tests simples fonctionnent plutôt bien avec le robotium, mais lorsque vous essayez d'avoir 2 tests dans la même instrumentation, vous obtenez un deuxième test suspendu pour toujours. J'ai également essayé de finaliser et de terminer toutes les activations, mais rien ne fonctionne. Le robotium devrait adresser ce problème. Leurs exemples ont toujours une seule classe d'essai.