Detox et Appium: Test d'interface automatisé dans React Native



Environnement mobile inconnu


Je suis peut-être, comme vous, venu chez React Native en tant que développeur JavaScript, plutôt qu'en tant que développeur d'applications mobiles natives. Un monde complètement nouveau avec ses propres nuances et astuces.

L'un des sujets les plus importants à étudier sera le test. Lorsque tout est plus ou moins clair avec les tests unitaires, que faire des tests d'interface et des tests de bout en bout? iOS Android Il existe un mélange de différents types d'appareils sur le marché.

Malgré le fait que la technologie elle-même soit relativement nouvelle, c'est toujours un environnement mobile et beaucoup doivent emprunter et apprendre du côté natif.

J'examinerai brièvement deux cadres auxquels il convient de prêter attention afin de me faciliter la vie en tant que développeur.

Appium


En utilisant Selenium WebDriver dans les coulisses, Appium est un cadre puissant avec une énorme communauté de développeurs d'applications mobiles natives. Sorti avant React.js, c'est un leader et n'a pas d'égal.

Débuter avec Appium est assez simple. En utilisant npm, nous installons les packages «appium» et «appium-doctor», nous pouvons globalement, nous pouvons le faire dans le cadre du projet. L'équipe «appium-doctor» nous indiquera ce qui doit être installé et configuré avant de commencer les travaux et, si possible, aidera à corriger les défauts. Lorsque tout est décidé, les packages sont installés et la configuration Jest est en place, nous pouvons exécuter le serveur Appium et les tests.

Je n'entrerai pas dans les détails de la configuration, mais voici à quoi ressemble un simple test avec la configuration (commentaires ajoutés):

/*  selenium webdriver  node */ import wd from 'wd' /* 60  ,    ,   */ jasmine.DEFAULT_TIMEOUT_INTERVAL = 60000 /*   Appium.    ,  localhost */ const URL = 'localhost' const PORT = 4723 /*   webdriver */ const driver = wd.promiseChainRemote(URL, PORT) /*  . *    Appium, *   ,   . */ const capabilities = { platformName: 'iOS', //  Android platformVersion: '12.1', //   deviceName: 'iPhone 8', //  “Android Emulator”     automationName: 'XCUITest', //   (UIAutomator2  Android) app: '/path/to/.app' //   .app ( Android  .apk) } beforeAll(async () => { try { //  ,    await driver.init(capabilities) //   await driver.sleep(4000) //  ,       ,   ! } catch(err) { console.log(err) //  ,   ,    } }) afterAll(async () => { try { await driver.quit() //   } catch(err) { console.error(err) } }); /* Jest,   ,   Appium! *     ,    * 'topLabel'  'subLabel'  *       Appium */ describe("Home Screen landing", () => { test("render search screen", async () => { let topLabel = await driver.elementById('topLabel') let subLabel = await driver.elementById('subLabel') expect(await topLabel.text()).toBe("OK") expect(await subLabel.text()).toBe(" ") }) }) 

Le test lui-même, ce sont les dernières lignes qui vérifient si le texte «OK» et «écran principal» sont à l'écran. Comme vous pouvez le voir, rien de spécial dans le test, le même Jest. La documentation sur le site Web d'Appium décrit toutes les fonctionnalités du framework, y compris des exemples JavaScript.

await driver.sleep(4000) n'aime pas await driver.sleep(4000) . Malheureusement, les tests n'ont aucune idée de ce qui se passe dans l'application. La soi-disant «boîte noire» ou Blackbox. Imaginez si vous écriviez du code sur Node, et avant la requête http, vous définiriez une minuterie au lieu d'utiliser la promesse ou le rappel. Voilà, la fragilité des tests d'interface.

Dans ce test simple, nous attendons 4 secondes pour lancer l'application. Au fil du temps et avec une augmentation du nombre de tests, nous réglerons plus souvent les temporisations - requêtes http, animation, React Native lui-même - le pont entre le code natif et JavaScript ne fait que compliquer la situation.

"Black Box", nous avons l'assemblage de l'application sans accès aux structures internes.


Qu'aimez-vous chez Appium?

  • 7+ ans dans l'industrie.
  • Fonctionnalités API étendues.
  • Aide facile à trouver (c'est aussi un inconvénient, la liste ci-dessous)
  • Prise en charge de différentes langues, y compris JavaScript.
  • Un environnement de développement JavaScript familier pour Jest.
  • Utilisé pour les tests de bout en bout dans MS AppCenter, BrowserStack et AWS DeviceFarm.
  • La possibilité de tester sur de vrais appareils.

Ce que je n'aime pas chez Appium

  • Les recherches Web renvoient des résultats pour différents langages de programmation, la plupart d'entre eux Java.
  • Test de la boîte noire (les tests ne connaissent pas les processus à l'intérieur de l'application).
  • Il n'y a pas de synchronisation avec l'application, la fragilité, React Native crée encore plus de problèmes.
  • testID pour une raison quelconque ne fonctionne pas sur Android.


Remarquez trois onglets: les journaux du serveur Appium, le bundler metro et le test lui-même.


Detox


Detox de Wix fonctionne de manière similaire à Appium. La principale différence est le test selon la stratégie de la «boîte grise». L'une des tâches des développeurs Detox était de résoudre les problèmes de fragilité - la tâche dans l'application ne sera pas démarrée avant la fin de la précédente et jusqu'à ce que l'application soit gratuite. Cela a été rendu possible grâce à un autre framework créé sous le nom EarlGrey.

Comme pour Appium, nous définissons les paramètres.

 /*     package.json,   */ const detox = require("detox"); const config = require("./package.json").detox; /*  Jest */ const adapter = require("detox/runners/jest/adapter"); /* , *   Jest */ jest.setTimeout(120000); jasmine.getEnv().addReporter(adapter); beforeAll(async () => { /*   */ await detox.init(config); }); /* beforeEach  afterEach   Detox, *   Jest *    */ beforeEach(async function() { await adapter.beforeEach(); }); afterAll(async () => { await adapter.afterAll(); await detox.cleanup(); }); 

Et en définissant dans package.json:

 "detox": { "configurations": { "ios.detox": { //   iOS (  detox test -c ios.detox) "binaryPath": "path/to/.app", "build": "xcodebuild -workspace ios/app.xcworkspace -scheme scheme -configuration Debug -sdk iphonesimulator -derivedDataPath ios/build", //  workspace  project.      debug  production (release). "type": "ios.simulator", "name": "iPhone 8" //   }, "android.detox": { //   Android (  detox test -c android.detox) "binaryPath": "path/to/.apk", "build": "cd android && ./gradlew assembleDebug assembleAndroidTest -DtestBuildType=debug && cd ..", //      debug  production (release). "type": "android.emulator", "name": "Pixel_2_API_28" //  . “adb devices”     Android } }, "test-runner": "jest", "runner-config": { "setupTestFrameworkScriptFile" : "./detox.init.js", //   "testEnvironment": "node", "testRegex": "(.*|\\.(ui))\\.(ts|tsx)$" //  ,     } "specs": "./__tests__/" //    } 

Écrire des tests est aussi simple que d'écrire Appium, mais en utilisant les fonctionnalités et les limites de Detox.

"Boîte grise", nous avons le montage de l'application et l'accès aux structures internes.


Ce que j'aime chez Detox

  • Créé par Wix pour React Native.
  • Axé sur JavaScript.
  • Test sur la stratégie de la "boîte grise".
  • Il fonctionne de manière synchrone avec l'application.

Ce que vous n'aimez pas chez Detox

  • Les possibilités ne sont pas aussi larges que celles d'Appium.
  • Petite communauté.

Fragilité


Bien que Detox utilise le principe de la «boîte grise», la fragilité est toujours présente. Le test avec saisie de texte et balayage n'a pas fonctionné comme il se doit dans 1 cas sur 10. Vous ne pouvez pas être sûr à 100% dans les tests d'interface.

La vitesse


Appium «ralentit» les minuteries «.sleep» réglées manuellement, Detox gagne dans ce cas, car tout est synchrone. En général, je ne tirerais aucune conclusion de ma part, car je n'ai pas écrit un grand nombre de tests identiques sur les deux plateformes. Dans les tests de 30 secondes et le test simple créé pour cet article, Detox a effectué quelques secondes plus rapidement. Si vous regardez deux plates-formes différentes, iOS et Android, les tests ont pris + - en même temps. La principale chose à retenir est que les tests d'interface prennent beaucoup plus de temps de test unitaire.

Que choisir


J'étudie toujours les deux frameworks et il faudra un certain temps pour comprendre tous leurs avantages, mais pour le moment, en tant que développeur JavaScript, je choisis Detox.

Essayez les deux, heureusement, il n'y en a que deux. Tout dépend de l'application sur laquelle vous travaillez et de l'équipe.

Tests d'interface dans l'équipe de développement - pour les développeurs, essayez Detox. Des tests de bout en bout plus complexes - il serait peut-être préférable de regarder de plus près Appium avec ses riches capacités API et sa prise en charge sur les plateformes BrowserStack, MS AppCenter et AWS DeviceFarm.

Les références


Il existe de nombreuses ressources et articles utiles, mais malheureusement en anglais. La première chose que je recommande. sites.

Appium

Detox

Source: https://habr.com/ru/post/fr434816/


All Articles