Kaspresso: le framework d'autotest que vous attendiez

Quiconque a été ou est engagé dans des autotests Android sait à quel point c'est pénible.
Vous vous fatiguez du volume des tâches et des problèmes pour que les vacances ne vous aident pas. Les gens ont même arrêté à cause des autotests.

La douleur, la souffrance et le tourment conduisent inévitablement à l'émergence de quelque chose de nouveau et de beau. Nous avons essayé de rassembler tous les râteaux sur lesquels nous devions marcher, avons combiné nos efforts avec les gars d'Avito et de HH et avons créé quelque chose qui rendrait votre relation avec les autotests incomparablement meilleure et plus fructueuse.

Rencontrez: Kaspresso - le cadre d'autotest que vous attendiez!



Je constate tout de suite qu'il y a deux vidéos de très bonne qualité sur le réseau dédiées à Kaspresso et AdbServer (auxiliaire pour Kaspresso, mais en même temps, un projet fort et indépendant):

1. Dmitry Movchan, Eugene Matsyuk - Comment commencer à écrire des autotests et ne pas devenir fou
2. Egor Kournikov - La seule chose dont vous avez besoin pour les tests d'interface utilisateur

Ils décrivent en détail l'histoire de la création de bibliothèques: comment nous sommes passés de la résolution d'un problème à la résolution d'un autre, et ce qui s'est finalement produit. Je le recommande vivement.

Par conséquent, dans l'article, je ne parlerai que des principaux points et puces afin que vous puissiez rapidement comprendre en quoi consiste ce cadre et quelles tâches il résout. Et les tripes et les détails peuvent être trouvés dans la vidéo et la documentation.

Pourquoi avons-nous même besoin de notre propre cadre?

Chaque développeur qui commence à écrire des autotests pose inévitablement des questions:

1. Comment commencer à écrire des autotests?
2. Quels outils choisir?
3. Que faire s'il n'y a pas d'outil nécessaire?
4. Quelles sont les meilleures pratiques?

À tout cela, ajoutez que chaque équipe essaie de résoudre ces problèmes à sa manière. En conséquence, il n'y a pas de réponse unique, il n'y a nulle part où jeter un œil sur la façon de le faire correctement. Par conséquent, l'écriture et la prise en charge des autotests coûtent cher aux entreprises, ce qui remet en question la faisabilité de l'automatisation en tant que telle.

Pendant ce temps, l'automatisation des tests poursuit de bons objectifs. Il vous permet d'avoir toujours un assistant vert et prêt à sortir. Et cela signifie que vous pouvez déployer la version rapidement.
Le seul problème est de trouver des réponses aux questions ci-dessus. Mais ils sont presque les mêmes pour toutes les équipes. Alors pourquoi ne pas automatiser leur solution?

Que voulons-nous du cadre?

Révélons un peu nos attentes du cadre.

Bonne lisibilité

Par défaut, seule la bibliothèque Espresso est disponible pour nous dans Android. Il y a bien sûr Appium + Cucumber, qui en théorie vous permet d'écrire des tests sur deux plateformes à la fois. Mais la communauté se dirige avec confiance vers le tout premier instrument. Je ne décrirai pas tous les avantages et les inconvénients des bibliothèques ci-dessus: le réseau regorge d'informations à ce sujet. Voici, par exemple, l'un des liens relativement récents: Appium vs Espresso. Que choisir et comment utiliser?

Alors, Espresso. Pas un mauvais outil, mais son api est un peu retourné. Jetez un œil à un code simple:

@Test fun espressoTest() { onView(allOf(allOf(withId(R.id.espresso), isDescendantOfA(withId(R.id.coffee_variates))), isDescendantOfA(withId(R.id.content)))) .check(matches(withEffectiveVisibility(View.VISIBLE))) } 

Vous devez penser à le comprendre, non?

Les dieux de Thaïlande et d'Australie nous ont présenté la bibliothèque Kakao , avec laquelle vous pouvez comprendre en un coup d'œil ce qui se passe dans votre test. Voici le même code, mais avec Kakao:

 @Test fun kakaoTest() { mainScreen { myView.isVisible() } } 

Bien mieux. Mais imaginez maintenant que vous avez automatisé un cas de test complet. À quoi ressemblerait le code?

 @RunWith(AndroidJUnit4::class) class OpenHomeScreenTest: TestCase() { @Test fun test() { MainScreen() { homeButton.click() } HomeScreen() { title { isVisible() hasAnyText() } } } } 

Le principal problème est que, en regardant ce test, il est difficile de le corréler avec le cas de test que vous avez automatisé. Vous pouvez bien sûr ajouter des journaux ou quelque chose comme ça. Ou entrez dsl, qui transforme immédiatement l'apparence de vos tests:

 @RunWith(AndroidJUnit4::class) class OpenHomeScreenTest: TestCase() { @Test fun test() { step(“1. Open Home screen”) { MainScreen() { homeButton.click() } } step(“2. Check Home title”) { HomeScreen() { title { isVisible() hasAnyText() } } } } } 

D'accord, ça a l'air complètement différent.

La stabilité

Toute bibliothèque pour ui-tests échoue. La même action peut être effectuée 50 fois avec succès et à la 51e pause sans raison apparente. Et à la 52e manche, tout va bien à nouveau. Et un tel "flacking" peut décemment gâcher vos nerfs.

Nous avons pensé, pourquoi ne pas essayer d'intercepter toutes les actions de Kakao-Espresso, et y ajouter déjà un comportement supplémentaire visant à gérer de telles erreurs aléatoires.

C'est ainsi que la version 2.1 de la bibliothèque Kakao est née, vous permettant de vous intégrer à tous les appels Espresso.

De plus, nous avons créé nos propres intercepteurs, avec lesquels vous pouvez modifier le comportement du cadran-pair ou, par exemple, simplement vous connecter. De plus, ces intercepteurs sont personnalisables, vous pouvez donc les personnaliser en fonction de vos besoins. En savoir plus dans le dock .

Plus précisément, dans le cadre de la lutte contre les tests floconneux - si certaines de vos actions ont levé une exception, Kaspresso essaiera:

• Faites défiler. Peut-être que votre vue n'est tout simplement pas visible à l'écran.
• Supprimez le dialogue système qui pourrait provenir de Dieu sait où.
• Répétez un appel interrompu pendant deux secondes.

Avec ces étapes, nous résolvons complètement le problème avec des tests feuilletés!

Journalisation

L'un des principaux problèmes qui accompagne les autotests est le manque de journalisation intelligible, qui n'est surtout pas suffisant lorsque le test se bloque. Asseyez-vous et demandez-vous ce qui est tombé et comment.

Grâce à l'interception susmentionnée, nous avons pu construire un système de journalisation assez étendu.

Prenons un exemple:





Par défaut, Kaspresso enregistre toutes vos actions, sélectionne chaque étape du test, affiche le temps d'exécution, etc.

Adb complet dans les tests Espresso

Initialement, adb n'est pas disponible dans les tests Espresso. Oui, il y a un shell adb , mais il y a beaucoup moins de fonctions qu'en plein adb . Mais il y a tellement de choses qui peuvent être utiles dans les tests.

Nous avons créé une bibliothèque AdbServer distincte qui retournera adb complet à vos tests! La vidéo ci-dessus détaille comment nous nous sommes battus et ce que nous avons vécu pour cela ( un et deux ).

Travailler avec Android OS

Les spécificités des tests de Kaspersky Lab sont telles que nous devons beaucoup travailler avec OS Android: configurer certains paramètres, télécharger des fichiers sur le système, etc. Tout cela nous a incités à standardiser tout notre travail avec le système, à créer un ensemble d'interfaces claires, accessible via un seul appareil de classe point d'entrée.

Quelles sont ces interfaces et que font-elles? Permettez-moi de vous donner quelques diapositives de la présentation de Yegor à titre d'illustration:









La documentation est ici .

Sous le capot, AdbServer et UiAutomator sont principalement utilisés.
Mais! Si vous n'êtes pas satisfait de l'implémentation d'une interface, vous pouvez définir votre implémentation via le configurateur.

Capture d'écran de DocLoc (Documentation et localisation)

Tous les projets où il y a une localisation, il est souvent nécessaire de prendre des captures d'écran dans différentes langues afin de les donner au traducteur comme illustrations. Après tout, il est très difficile de faire une traduction correcte sans voir où et comment une ligne particulière est utilisée. Par conséquent, je veux pouvoir prendre des captures d'écran rapidement et immédiatement dans toutes les langues. Y compris des captures d'écran des boîtes de dialogue système. Vous pouvez également avoir besoin de captures d'écran sur les écrans hérités et sans refactoring global.

Tout cela vous permet de faire Kaspresso hors de la boîte. En savoir plus dans la documentation .

Architecture et bonnes pratiques

L'une des tâches clés de Kaspresso était de créer un tel DSL qui vous pousserait vers la bonne architecture de test et leur écriture correcte.

De nombreuses copies ont été cassées sur ce sujet, car vous ne trouverez malheureusement de telles règles nulle part. Tout ce que vous pouvez trouver sont des articles sur l' objet de page .

Par conséquent, nous n'avons épargné aucun effort et avons souligné ces problèmes dans la documentation , et dans la vidéo une fois et la vidéo deux .
De plus, Sasha Blinov a écrit un excellent article sur le Kotlin DSL et les tests élégants . Les dsl décrits dans l'article sont fournis par Kaspresso.

De retour chez Mobius, nous avons proposé une option sur la façon d'accélérer l'impact des autotests et de les intégrer rapidement dans PullRequest, en contournant les problèmes d'infrastructure inévitables. Nous en parlons plus en détail ici .

Comment connecter et configurer Kaspresso si vous avez déjà de nombreux tests

Le charme principal est que si vous avez déjà de nombreux tests écrits en Kakao et que vous souhaitez implémenter Kaspresso, vous n'avez rien à réécrire! Héritez simplement vos classes de test de la classe spéciale TestCase. Et c'est tout!

C'était:

 @RunWith(AndroidJUnit4::class) class OpenHomeScreenTest { private val mainScreen = MainScreen() private val homeScreen = HomeScreen() @get:Rule val activityTestRule = ActivityTestRule(MainActivity::class.java, true, false) @Test fun test() { ... } } 

C'est devenu:

 @RunWith(AndroidJUnit4::class) class OpenHomeScreenTest : TestCase() { private val mainScreen = MainScreen() private val homeScreen = HomeScreen() @get:Rule val activityTestRule = ActivityTestRule(MainActivity::class.java, true, false) @Test fun test() { ... } } 

Et si vous n'aimez pas l'héritage, utilisez une classe TestRule similaire.

Comme nous l'avons déjà mentionné, Kaspresso est un cadre très flexible et personnalisable. Tous les paramètres sont disponibles via la classe Kaspresso du même nom.

Le paramètre par défaut est par défaut. Si vous souhaitez personnaliser quelque chose, cela ressemblera à ceci:

 @RunWith(AndroidJUnit4::class) class OpenHomeScreenTest : TestCase( Kaspresso.Builder.default().apply { viewBehaviorInterceptors.add(MyInterceptor()) flakySafetyParams.timeoutMs = 1_000 } ) { private val mainScreen = MainScreen() private val homeScreen = HomeScreen() @get:Rule val activityTestRule = ActivityTestRule(MainActivity::class.java, true, false) @Test fun test() { ... } } 

Autrement dit, Kaspresso.Builder est disponible via le constructeur TestCase , où vous définissez tous les paramètres dont vous avez besoin. Les détails sur le configurateur sont écrits dans la documentation .

Plans immédiats

Dans un avenir très proche, nous prévoyons d'ajouter les éléments suivants:

Afficher les étapes de test dans Allure (bonjour aux gars de HeadHunter)

Grâce à un intercepteur spécial, nous préparons les données pour Marathon . Cela nous permet de voir les rapports Allure de la nature suivante:



Détails dans PR # 4

PS PR est déjà dans la version 1.0.1, nous préparons maintenant le PR correspondant à Marathon .
Pss. Il y a une idée pour attacher un morceau spécifique du journal à chaque étape, et ajouter une capture d'écran à l'étape "tombée".

Test des scripts de mise à niveau

Il est souvent nécessaire de vérifier l'exactitude des mises à niveau des applications. Oui, certains chèques peuvent être transférés aux tests unitaires. Mais nous aimerions être calmes pour l'ensemble de l'application dans son ensemble.

Malheureusement, sur un Espresso pur, il est impossible de le faire, car si nous réinstallons l'apk testé, le test échouera. Vous pouvez en quelque sorte essayer de jouer avec le coureur, mais il m'est difficile d'imaginer à quoi ressembleront ces améliorations et à quel point elles seront stables.
Par conséquent, chez Kaspresso, nous préparons une solution à ce problème, basée sur UiAutomator. Cependant, en haut, vous aurez tout de même le même dsl familier, très similaire à Kakao et avec le même support pour l'intersection.

Liens utiles

Kaspresso
AdbServer
Chat , dans lequel nous serons toujours heureux de répondre à toutes vos questions

Remerciements

Un merci spécial à tous ceux qui ont participé à l'élaboration du projet.
C'était très difficile, mais sacrément cool!

Au lieu d'une conclusion

Nous pensons que Kaspresso et AdbServer vous rendront la vie meilleure.
Nous apprécions vos commentaires, recommandations, Yishuyam et PulRequest!
Et n'oubliez pas de mettre un astérisque, s'il vous plaît!

PS Et à la toute fin un petit sondage =)