Appium vs Native Frameworks: un confronto

Di Kouros Aliabadi e Rohan Janjua

Questo post è un riassunto delle nostre esperienze e non necessariamente l'intero quadro. Forniremo alcuni link e ci baseremo su questo in post futuri per aiutarti nella tua ricerca. Speriamo che questo sia un buon punto di partenza per chiunque desideri fare la scelta tra alcuni dei principali approcci di automazione mobile.

Ci sono strumenti di automazione alternativi là fuori ma per il contesto di questo post del blog ci limiteremo a questo Appium e agli strumenti nativi predefiniti per iOS e Android: XCUITests ed Espresso rispettivamente.

Appium:

Appium è stato lo strumento defacto per l'automazione mobile negli ultimi anni, fornendo un'esperienza simile al selenio. Fino ad ora è stata una delle scelte più praticabili dal punto di vista professionale per una serie di motivi.

  1. In primo luogo è l'agnostico della lingua, con il supporto di una vasta gamma di lingue popolari. Se la tua lingua preferita ha un client webdriver, puoi usare Appium. Questo dipende dal jsonWireProtocol condiviso. Questo è di grande convenienza in quanto consente agli sviluppatori di test di raccogliere rapidamente lo strumento. Le lingue supportate includono, ma non sono limitate a Java, C #, JavaScript, Python e ruby.
  2. È molto semplice raccogliere e iniziare facilmente. Analogamente al punto precedente, Appium ha molte somiglianze con il webdriver Selenium. Il vantaggio di questo è che se gli sviluppatori di test sono abituati a scrivere test web con selenio webdriver, allora Appium dovrebbe essere relativamente semplice da prendere e abbastanza intuitivo.
  3. Appium consente di testare più piattaforme dalla stessa base di codice di test. Per coloro che lavorano in un team di test centralizzato o in un team che lavora sia su iOS che su Android, può ridurre la quantità di codice della piastra di caldaia necessaria per lavorare con l'infrastruttura di test e gli emulatori.
  4. Inoltre, nell'esperienza di alcuni dei nostri tecnici di test, il supporto per le app native che utilizzano visualizzazioni Web è migliore su Appium rispetto alla maggior parte degli altri concorrenti. Il supporto fornito da Appium può essere prezioso quando si tratta di automatizzare le app ibride.

Ci sono anche alcuni svantaggi nell'utilizzo di Appium:

  1. Nella nostra esperienza, i test Appium sono molto più lenti rispetto ai test scritti in XCUITests o Espresso
  2. Il codice di test non vive con il codice di sviluppo. Ora questo potrebbe essere oggetto di dibattito, ma riteniamo fermamente che il codice di test e il codice di sviluppo debbano vivere vicini.
  3. Per testare le app multipiattaforma ci sarà sempre un certo grado di complessità tecnica coinvolta in Appium. O devi:
  4. Mantenere 2 set di PageObjects / ScreenObjects che aderiscono a un singolo contratto in modo che possano essere chiamati da un solo set di test.
  5. Scrivi 2 serie di test
  6. Assicurati che gli sviluppatori utilizzino lo stesso ID su entrambe le app

Strumenti nativi:

Le due piattaforme principali per lo sviluppo di app ora dispongono di strumenti di automazione dell'interfaccia utente molto competitivi: XCUITest ed Espresso. La maturità di questi due strumenti è notevolmente migliorata e in una recente conferenza al WWDC 2017, Apple ha chiarito che sono molto attivi nel migliorare i propri strumenti di automazione dell'interfaccia utente.

  1. Vi è un vantaggio fondamentale nell'utilizzo di XCUITest ed Espresso: sono creati dai fornitori di piattaforme: Apple e Google. Questi strumenti saranno sempre all'avanguardia per i test iOS e Android. Qualsiasi nuova funzionalità di Appium sarebbe nella maggior parte dei casi costruita sulla funzionalità di uno strumento nativo esistente.
  2. Un altro grande vantaggio ai nostri occhi è che includerai il codice di prova con il codice sorgente del tuo progetto. Questo potrebbe forse essere leggermente discusso, ma ne discuteremo in un prossimo post. Per ora affermeremo semplicemente che crediamo che includere il tuo codice di test all'interno dello stesso progetto e nella stessa lingua utilizzata dai tuoi sviluppatori abbia grandi vantaggi. Fornisce maggiori incentivi alla collaborazione all'interno del team e consente a tutti di contribuire facilmente a questo aspetto dello sviluppo del software.
  3. A volte si suppone che l'esperienza Android sia diversa dall'esperienza iOS, scrivendo i test per ogni piattaforma non è necessario complicare il framework di test per gestire queste situazioni.
  4. Molto meno traballante. Gli strumenti nativi sono solo meno traballanti. Potrebbe avere qualcosa a che fare con un numero minore di parti mobili e meno livelli di comunicazione tra il codice di test e la strumentazione, ma i test scritti con strumenti nativi sembrano essere molto meno sfibrati.
  5. Puoi usare un set di strumenti molto più grande che se usi uno strumento come Appium. Ad esempio con Android hai accesso sia alla libreria UiAutomator che alla libreria Espresso.

Caffè espresso:

Lo strumento di test Android di Google Espresso ha alcune caratteristiche proprie che meritano di essere menzionate.

  1. L'espresso è molto veloce, non abbiamo mai visto qualcosa di così veloce nell'automazione dell'interfaccia utente. È come il flash dell'automazione dell'interfaccia utente, nessun altro strumento si avvicina alla sua velocità.
  2. Non devi preoccuparti di aspettare che accadano o finiscano le cose nel tuo codice di prova, poiché Espresso lo gestisce per te, esclusi alcuni casi eccezionali. Questo fondamentalmente elimina dall'equazione la cosa più fragile dell'automazione dell'interfaccia utente.
  3. Espresso adotta un approccio di test "scatola grigia". Scatola non abbastanza nera, non abbastanza bianca. Con espresso il tester ha un controllo molto maggiore sull'applicazione rispetto a uno strumento a scatola nera come appium.
  4. Espresso consente al tester di utilizzare strumenti come Robolectric, un framework per eseguire Android SDK senza avviare un simulatore o collegare un dispositivo. Ciò significa che i test si avviano più velocemente e vengono eseguiti anche più velocemente.

Esiste un framework simile a Espresso, anch'esso creato da Google, per i test iOS che vale la pena menzionare qui: EarlGrey. Non l'abbiamo usato, ma se porta alcuni dei vantaggi di Espresso su iOS vale la pena esplorare.

Ci sono anche alcuni svantaggi nell'uso degli strumenti di test nativi:

  1. Se stai sviluppando un'app multipiattaforma, dovrai potenzialmente mantenere il doppio del numero di test rispetto a se hai utilizzato uno strumento come Appium.
  2. Se stai sviluppando un'app multipiattaforma, dovrai conoscere due lingue.
  3. Più complessità può essere coinvolta in questo approccio. Questo è un effetto collaterale della potenza extra e dell'accesso che uno strumento come Espresso può dare al tester. Ad esempio Espresso attende automaticamente il completamento degli eventi nell'applicazione in prova utilizzando un IdlingResource. Tuttavia, in alcuni casi il tester dovrà implementare IdlingResource manualmente.
  4. Con uno strumento come Espresso, il tester può mettere l'applicazione in uno stato che potrebbe non essere in grado di raggiungere dal punto di vista dell'utente. Ancora una volta, questo è l'altro lato del potere extra che ottieni.