React Native Uygulamaları için Çeşitli Test Otomasyon Çerçeveleri

Çıta, günümüzün mobil uygulamaları için yüksek olarak ayarlanmıştır. İlk olarak, uygulamalar, uygulama pazarlarının beklediği kalite standardını karşılamalıdır. İkincisi, mobil uygulama kullanıcıları çok talepkar. İndirilebilecek çok sayıda alternatif mevcuttur, bu nedenle kullanıcılar buggy bir uygulamaya müsamaha göstermeyecektir. Mobil uygulamalar insanların hayatlarının çok önemli bir parçası haline geldiğinden, kullanıcılar bir uygulamaya duydukları sevgiyi veya nefreti paylaşmaktan çekinmeyecekler ve bu geri bildirimler milyonlarca kullanıcının önüne saniyeler içinde ulaşıyor.

Smashing hakkında daha fazla okuma :

• JavaScript ile İlk iOS Uygulamanızı Oluşturma
• Neden Mobil Uygulamanız İçin React Native'i Düşünmelisiniz?
• Uygulamalar, Oyunlar ve Mobil Web İçin Test Otomasyonu
• React, Node ve Express ile Sunucu Tarafı Oluşturma
• İstemci Tarafından Oluşturulan Erişilebilirlik Üzerine Notlar

Mobil her zamankinden daha önemli. Ancak bir uygulamayı tam olarak doğru hale getirmek, farklı işletim sistemi sürümleri, ekran çözünürlükleri, yonga setleri ve diğer donanım özellikleriyle tüm olası cihazlarda çalışmasını sağlamak ve tüm olası yapılandırmalarda kullanıcı deneyimini sorunsuz hale getirmek zorlu bir iştir.

Yerel mobil uygulamalar oluşturmak için bir sürü harika teknoloji, araç, çerçeve ve açık kaynaklı bileşen mevcuttur. React Native sahneye hangi değeri getiriyor ve onunla oluşturulan uygulamaların hedef kitleleri tarafından iyi karşılandığından nasıl emin olabiliriz?

Bu makalede, React Native uygulamalarını test etmek için nelerin mevcut olduğuna bakacağız. İlk olarak, bu testlerin nasıl uygulanacağına bakmadan önce React Native'in bazı temel özelliklerini açıklayacağım. İkinci olarak, her biri için örnekler vererek test yöntemlerini ve çerçevelerini üç düzeyde (birim, entegrasyon, işlevsel) kategorize edeceğim. Son olarak, işlevsel uygulama testi için en popüler açık kaynaklı test otomasyon çerçevelerini kullanarak testlerin nasıl uygulanacağına dair basit örnekler sağlayacağım.

React Native Uygulamalarının Temel Mimarisi

Her şey, Facebook'un web geliştiricilerine çerçevesini tanıttığı üç yıldan uzun bir süre önce React ile başladı. Sadece Facebook tarafından yazıldığı ve geliştirildiği için değil, aynı zamanda web geliştiricilerine sağladığı yetenekler ve özellikle uygulama oluşturma şeklimizi nasıl değiştirdiği nedeniyle popüler olması gerekiyordu.

Bu tür “bir kez öğren, her yere yaz” çerçevesi kavramı yeni değildi; JavaScript kitaplıklarının benzer şeyler yaptığını görmüştük (diğerlerinin yanı sıra Sencha, PhoneGap ve Appcelerator), ancak React'te geliştiricilerin alışkanlıklarını ve bir uygulamanın kullanıcı arayüzünü ayrı bileşenlere nasıl ayırdıklarını etkileyen daha iyi bir şey vardı.

React Native, oluşturma için DOM kullanmaz. Bunun yerine, yerel UI görünümleriyle işlenir; bu, işletim sistemi tarafından sağlanan yerel bileşenleri kullandığınız anlamına gelir. DOM API'sini daha bildirimsel bir API ile değiştirdiğiniz bu tür ürün oluşturma akışı, geliştiricilere daha uyumlu ve basitleştirilmiş bir soyutlama düzeyi sağlar.

React Native ile ilgili en önemli şey, React programlama modelini mobil uygulamalara, geliştirmeye ve test etmeye getirmesidir. Aslında doğrudan platformlar arası bir araç veya çerçeve olarak çalışmıyor, ancak bu yeni platformda mobil uygulamalar oluşturma eğilimini hızlandırıyor. Ve bu, React Native'i bu kadar güçlü, öğrenmesi kolay ve bu yeni platformda yazması kolay yapan temel taşlardan biridir.

Yerel mobilin web'e göre avantajının yanı sıra en büyük farkı, bir tarayıcıda JavaScript tabanlı bir uygulama çalıştırmak ve HTML öğelerini göstermek yerine, artık platforma özel hale gelen uygulamalarda gömülü JavaScriptCore'a güvenmemizdir. UI öğeleri.

Farklı Düzeylerde Test Otomasyonu: Birim, Entegrasyon, Bileşen ve İşlevsel

Tüm mobil yazılımlar, kompozisyon kullanılarak oluşturulmuştur. Android ve iOS'ta bu, küçük yazılım bileşenlerinin, uygulamanın hedefleri ve gereksinimleri karşılanana kadar daha büyük, daha yüksek işlevselliğe sahip daha üst düzey bileşenler oluşturmak üzere birlikte düzenlendiği anlamına gelir. İyi bir test uygulaması, kompozisyonun tüm seviyelerinde işlevselliği kapsayan testler yapmaktır.

Bu makalede, test yöntemlerini ve otomasyon çerçevelerini üç düzeyde ele alacağım. Öncelikli odak noktası en üst düzeyde işlevsel testtir, ancak React Native uygulamaları en azından aşağıdaki düzeylerde test edilebilir ve testler otomatikleştirilebilir:

• Birim testi
  Bu, JavaScript nesnelerini ve yöntemlerini bileşen düzeyinde test etmek kadar basit olabilir.
• Bileşen testi
  Her bileşen görsel veya işlevsel olarak test edilebilir. ReactTestUtils, React bileşenlerini test etmek için basit bir çerçeve sağlar.
• Entegrasyon testi
  Daha sonra entegrasyon testi gelir ve bir grup farklı ünitenin tipik olarak bir varlık olarak test edildiği bir aşamadır.
• Fonksiyonel test
  İşlevsel test, kullanıcı gereksinimlerine ve etkileşimlerine odaklanan bir tür kara kutu testidir ve temel alınan tüm yazılımları, tüm kullanıcı etkileşimlerini ve bir varlık olarak uygulamayı kapsar.

ReactTestUtils'e ek olarak, React Native kullanışlı birim test yöntemleri sağlar, ancak bunların hiçbiri uygulamanın gerçek mantığını tam olarak kapsamaz. Bu nedenle, React Native üzerine kurulu mobil uygulamalar, işlevsel UI testlerinden daha fazla yararlanır. Çeşitli işlevsel test otomasyon çerçeveleri mevcuttur ve bu makalede en popüler olanlardan birkaçına bakacağız.

Birim testi bileşen düzeyinde yapılabilirken, işlevsel test otomasyonu, bir React Native uygulamasında daha büyük varlıkları test etmek için daha iyi yetenekler sağlar. React Native ile, geleneksel JavaScript kitaplıkları kullanılarak ve React Native'i yerel bileşenler yerine normal bileşenleri döndürmeye zorlayarak, bileşen mantık birimi testi tek başına yapılabilir. İşlevsel test-otomasyon çerçeveleriyle, UI bileşenleri uygulamanın bir parçasıdır ve bir bütün olarak test edilmesi kolaydır.

Bu çerçeveleri, aşağıdaki resimde gösterildiği gibi, platformlar arası çerçeveler ve platforma özel çerçeveler olarak ayıracağım.

React Native uygulamalarının en iyi yanı, her iki büyük mobil platform (Android ve iOS) için tamamen yerel olmalarıdır. Bu, test amacıyla daha fazla çerçeve, araç ve yerel yöntem elde ettiğimiz anlamına gelir. İşlevsel test otomasyon çerçevelerine aşağıdaki "İşlevsel Test Otomasyon Çerçevelerini React Native Uygulamalarıyla Kullanmak" başlıklı bölümde bakacağız.

Örneklemek için bir JavaScript testi kullanarak birim test yetenekleriyle başlayalım.

Jest ve Jasmine ile Birim Testi

Varsayılan olarak React Native, birim testi için Jest testleri sağlar ve bu hem Android hem de iOS için çalışır. Şu anda, test kapsamı mükemmel değil, ancak Facebook'a göre, React Native'de daha fazla birim testi özelliği sunulacak ve kullanıcılar zaten kendilerininkini oluşturabilir.

Jest, JavaScript kodunu test etmek için temel olarak Jasmine davranışa dayalı çerçeveyi kullanır. Her test durumu, TestCase sınıfını nasıl kullandığına benzer şekilde bir describe() işlev çağrısından başlar. describe() işlevi iki parametre alır: test senaryosunun açıklaması ve başlığı ve yürütülecek işlev. it() işlevi, tüm test adımlarını içerir ve (JUnit'e benzer) bir dizi expect() işlevi sağlar.

Burada bir oynatıcı uygulaması için bir Jasmine test komut dosyası örneği verilmiştir.

 describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });

Bu temel örnek, Jasmine'in bir uygulamanın işlevselliğini test etmek için nasıl kullanılabileceğini gösterir, ancak yöntem düzeyinde teste odaklanmayı sürdürür. Ayrıca, React Native, entegre bileşenleri test etmek için bazı temel yetenekler sağlar. Bu, hem yerel hem de JavaScript bileşenleri için çalışır ve aralarında bir köprü aracılığıyla iletişimi sağlar.

Entegrasyon Testi

Şu anda, React Native topluluğunda vurgulanan entegrasyon testleri yalnızca iOS için mevcuttur ve bileşenleri test etme yetenekleri çok sınırlıdır. İletişim köprüden geçer ve hem yerel hem de JavaScript bileşenleri gerektirir. Bu işlevsellik için, özelleştirilmiş entegrasyon testlerini uygulamak için iki bileşen mevcuttur, RCTestRunner ve RCTestModule.

Bir iOS uygulamasının test iskeletini oluşturmaya yönelik temel bir Objective-C örneği şu şekilde başlar:

 @implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @end

Ancak, entegrasyon testini çalıştırmanın ve bunu Android ve iOS'a genişletmenin başka yolları da vardır. Hem birim hem de entegrasyon testlerini çalıştırmak için iyi bir alternatif, Node.js üzerinde çalışan zengin özelliklere sahip bir JavaScript test çerçevesi sağlayan Mocha'dır. Mocha ayrıca test için davranış odaklı geliştirme (BDD), test odaklı geliştirme (TDD) ve QUnit arayüzleri sağlar.

İşlevsel UI testi için, Appium, Calabash, XCTest ve birkaç tane daha dahil olmak üzere en belirgin ve en çok kullanılan test otomasyon çerçevelerini ele alacağım.

React Native Uygulamaları ile Fonksiyonel Test Otomasyon Çerçevelerini Kullanma

Uygulama geliştirme sürecini kolaylaştırmak ve test kapsamını en üst düzeye çıkarmak için, aralarından seçim yapabileceğiniz çok sayıda açık kaynaklı test otomasyonu çerçevesine sahibiz.

Uygulamanız birkaç işletim sistemi platformunda çalışacaksa en iyi seçim, birden çok platformu destekleyen ve test otomasyonu için sağlam bir temel sağlayan bir çerçevedir. Mobilde "çapraz platform" terimi, hem Android hem de iOS için aynı API'yi, araçları ve yetenekleri sağlayan bir çerçeveyi ifade eder.

Ayrıca, platforma özel bir dizi harika çerçeve mevcuttur. Doğal olarak, her çerçeve belirli bir platform için oluşturulmuştur ve çoğu durumda bu platform için benimsenmesi daha kolaydır. Appium ve Calabash'a ek olarak, bu makalede platforma özel dört çerçeveyi ele alacağım: Android için Robotium ve Espresso ve iOS için XCTest ve EarlGrey.

Test otomasyonu söz konusu olduğunda, React Native ile oluşturulan uygulamaların hem iOS hem de Android'de tamamen yerel olduğunu unutmayın; bu nedenle, işlevsel test otomasyon çerçeveleri onlarla iyi çalışacaktır.

Her çerçeveyle kullanacağım örnek, çok temel bir radyo düğmesi kullanıcı arabiriminin bir uygulamasıdır.

 <Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio>

Aşağıdaki her çerçeve bölümünde yer alan test snippet'i, test komut dosyasının her bir UI öğesiyle nasıl ilgilendiğini ve tıklamaların ve diğer kullanıcı girdilerinin nasıl işlendiğini gösterir. Örneklerin amacı, adım adım talimatlar sağlamak değil, örnekleri karşılaştırmak ve bugün test otomasyonu için nelerin mevcut olduğunu ve test için hangi programlama dillerinin kullanılabileceğini göstermektir.

Platformlar Arası Çerçeveler

Belirtildiği gibi, React Native aslında platformlar arası bir çerçeve değildir, ancak diğer platformlarda benimsenmesi kolaydır. Sonraki iki bölümde, mobil test ve mobil test otomasyonu için iki popüler platformlar arası test otomasyonu çerçevesinden geçeceğiz.

Appium

Appium, yerel, karma ve mobil web uygulamaları için iyi çalışan bir inceleme aracına sahip açık kaynaklı bir test otomasyon çerçevesidir. Selenium WebDriver kullanarak iOS ve Android uygulamalarıyla etkileşim kurmak için JSONWireProtocol'u dahili olarak kullanır. Bu nedenle, Appium mobil web için de son derece iyi çalışıyor ve Selenium web testi için kullanılıyorsa kullanım durumları çok benzer.

Aslında, Appium geçen yıl mobil test otomasyonunda yükselen bir yıldız oldu. Başlangıçta, hem büyük platformlar, hem de Android ve iOS için çapraz platform desteği sağlamak üzere inşa edildi.

Çapraz platform olmak, çerçevenin ve komut dosyalarının her iki platformda da tamamen aynı şekilde çalıştığı anlamına gelir. Ek olarak, Appium harika programlama dili desteği sağlar - geliştiriciler favori dillerini (örneğin Java, Ruby, Python, C#), araçları ve ortamı kullanarak testler yazabilir. Başlamak, yeniden kullanılabilir testler oluşturmak ve sürdürmek ve bu testleri gerçek fiziksel cihazlarda yürütmek de kolaydır.

React Native destekli uygulamalar söz konusu olduğunda, JavaScript mutlaka gerekli değildir; testler herhangi bir dilde yazılabilir. Örneğin, Appium komut dosyaları şöyle görünebilir:

 driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();

Peki, bu WebDriver işlevleri, cihazlarda çalışan uygulamalara nasıl erişiyor? Temel olarak, Appium cihazda veya öykünücüde bir test komut dosyası başlatır, ardından bir sunucu oluşturur ve ana Appium sunucusundan gelen komutları dinler. Selenium istemci kitaplıklarından HTTP istekleri alan Selenium sunucusuyla aynıdır. Android ve iOS arasındaki fark aşağıdaki resimde gösterilmektedir:

iOS ile Selenium WebDriver, Appium betiğinden bir komut alır (örneğin, click() ) ve bunu bir HTTP isteği aracılığıyla Appium sunucusuna JSON biçiminde gönderir. Appium, otomasyon bağlamını bilir ve bu komutu Instruments komut istemcisinin onu almasını ve iOS Instruments ortamında bootstrap.js ile yürütmesini bekleyen Instruments komut sunucusuna gönderir. Komut yürütüldüğünde, Instruments komut istemcisi mesajı, komutla ilgili her şeyi konsolunda günlüğe kaydeden Appium sunucusuna geri gönderir. Bu döngü, test komut dosyası bitene kadar devam eder.

Android'de, kullanılan çerçevelerin Selendroid ve UiAutomator olması dışında işler neredeyse aynı şekilde çalışır. Kısacası, Appium, WebDriver komutlarını UiAutomator (API seviye 17 veya üstü) veya Selendroid (API seviye 16 veya altı) komutlarına çevirir. Fiziksel bir aygıtta, bootstrap.jar , bir TCP istemcisinden komutları alan bir TCP sunucusunu başlatır. İşlem iOS'ta benzer.

Appium'u kullanmaya başlamakla ilgileniyorsanız, adım adım talimatlar ve Appium eğitimleri de dahil olmak üzere birçok materyal mevcuttur.

su kabağı

Bir başka harika platformlar arası test çerçevesi, herkesin mobil uygulamalar için testler yazmasını sağlayan Calabash'tır. Temel fark, Calabash testlerinin Salatalık dilinde yazılmış olmasıdır. Testler için bu tür bir dili kullanmanın ardındaki fikir harika: Testin kendisi bir spesifikasyon gibidir ve tüm testler basit ve okunması kolay ancak otomasyon sistemi tarafından yürütülebilir.

Appium ile karşılaştırıldığında, Calabash, Android ve iOS için platformlar arası testler oluşturmanın daha kolay bir yolunu sunar. Bunun nedeni, Calabash testlerini her iki platformda da aynı kılan basit kelime dağarcığı ve spesifikasyon odaklı dildir. Gerçek testler Gherkin'de yazılmıştır ve Salatalık'ta çalıştırılır.

Bu yetenekler nedeniyle, Android'de ve iOS uygulamalarında çalışan Calabash arasındaki farklar küçüktür. Yine, tüm bileşenler ve kullanıcı arayüzleri bu platformlara tamamen yerel olduğundan, React Native uygulamaları için herhangi bir ima yoktur.

Bununla birlikte, temel test etme ve test oluşturma akışı aynı kalır. Calabash (ve Gherkin) testleri özellikler, senaryolar ve adımlardan oluşur. Önerilen yaklaşım, önce en üst düzey açıklamaları tamamlamaktır: özellikler, ardından senaryolar ve ardından gerçek adımlar. İyi bir kural, önce Calabash özelliklerini oluşturmaktır.

Aşağıdaki örnek, uygulamamızın ve UI bileşenlerinin (radyo düğmeleri, metin alanı ve düğme) Calabash'ta nasıl uygulanacağını gösterir:

 Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"

Adımlar genellikle given anahtar sözcüklerden biriyle başlar, then , when and veya but . Ancak, zorunda değiller; yerine * kullanabilirler.

Calabash, geliştirici olmayanlar tarafından da yaygın olarak kullanılmaktadır ve anlaşılması kolay dili ve mantığı nedeniyle ürün özellikleri ve dokümantasyonu için kullanılabilir. Sonunda, özellikler ve senaryolar Ruby koduna sarılır.

Calabash'ı kurmak ve onunla çalışmaya başlamak kolaydır. Bundler ve Ruby (veya rbenv) kuruluysa, konsolunuzda şu birkaç satıra tıklamanız yeterlidir; yakında bir Calabash ortamı kurulacaktır:

 $ gem install calabash-android $ gem install calabash-cucumber

Bu, Calabash-Android ve Calabash-iOS kurulumunu halledecek ve test otomasyonu yolculuğunuz başlayabilir.

Platforma Özgü Çerçeveler

Android ve iOS uygulamalarında testleri otomatikleştirme söz konusu olduğunda, platforma özel çerçeveleri platformlar arası çerçevelere göre kullanmanın belirli avantajları vardır. Örneğin, bazı çerçeveler, bir uygulama geliştirme aşamasındayken kolayca erişilebilen SDK'lara ve IDE'lere yakın olarak oluşturulmuştur. Android ve iOS için bu tür çerçevelerin birkaç örneğine bakalım.

Robotium ve ExtSolo (Android)

Robotium, yerel ve hibrit Android uygulamaları için çalışan ilk test çerçevelerinden biriydi. Robotium ile oluşturulan UI testleri, birden fazla Android etkinliğini kapsayan ve yöneten Android uygulamaları için işlevsel, sistem ve kullanıcı kabul testleri sağlar. Aslında, Robotium, API seviyesi 8'den başlayarak Android'in çok erken sürümleri için destek sağlar.

Yakın zamanda Robotium, uygulama testi için çeşitli kullanışlı özellikler sağlayan ExtSolo kitaplığıyla genişletildi:

• herhangi bir ekran çözünürlüğü için x ve y tıklamalarının otomatik ölçeklendirilmesi;
• çok yollu sürükler;
• test hatası anında otomatik ekran görüntüsü yakalama;
• sahte konumlar (GPS koordinatları);
• Android cihaz dilinin değiştirilmesi;
• Wi-Fi bağlantısının kontrolü;

Java koduyla, herhangi bir Java SDK ve IDE kullanarak testler oluşturmak kolaydır. Bu örnekte kullanılan birincil işlev, id özniteliği tarafından tanımlanan bir görünümü bulan findViewById . UI öğesi ayrıca bir ad, sınıf veya başka bir öznitelikle de tanımlanabilir. id özelliğine sahip kod örneğimiz şöyle görünür:

 solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));

Robotium burada id , açıklama ve diğer özelliklere göre UI öğelerini bulmaya çalışıyor. Ne yazık ki, bu her zaman en iyi yaklaşım değildir ve mutlaka web görünümü bileşenleriyle iyi çalışmaz. Ancak, ExtSolo kitaplığının yardımıyla kullanıcılar, çözünürlükle ölçeklenen UI öğelerinde tıklamaları ve diğer etkileşimleri tanımlayabilir. Ayrıca, sabit kodlama koordinatları mümkündür ve bunlar ekran çözünürlüğü değiştiğinde ölçeklenir.

Robotium kullanıyorsanız, Robotium ExtSolo'yu kullanmaya başlamak kolay ve zahmetsizdir. Depoyu kendiniz için klonlayın ve kütüphaneyi oluşturun:

 $ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrument

Bundan sonra, yakın zamanda oluşturulmuş .jar dosyasını Android Studio projenizdeki libs klasörüne yerleştirin ve projenizin buna bağlı olduğundan emin olun. Tüm bu harika ek özellikler ve hizmetler artık çalışma alanınızda.

Espresso (Android)

Espresso test çerçevesi, bir Android uygulaması için kullanıcı etkileşimlerini simüle etmek üzere UI testleri yazmak için API'ler sağlar. Espresso API hafiftir ve üç ana bileşen sağlar: viewMatchers , viewActions ve viewAssertions .

Espresso'nun güzelliği, test edilen test yöntemlerinin ve UI öğelerinin otomatik senkronizasyonunu sağlamasıdır. Örneğin, test komut dosyası bir düğmeye basmak istiyorsa ancak düğme henüz ekranda görünmüyorsa, bu düğmeye basılana kadar bekleyecektir (yani görünür ve bir tıklama gerçekleşebilir). Bu, test komut dosyalarının herhangi bir uyku veya bekleme komutu içermesi gerekmediğinden test yürütmesini çok hızlı hale getirir. Ayrıca, geliştiricilerin zamanlamayla ilgili sorunları ele almak için ek mantığa ihtiyacı yoktur.

 // R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());

Espresso'nun kendi artıları ve eksileri vardır ve hafif API nedeniyle geliştiriciler için pek fazla ek hizmet veya işlev çağrısı yoktur. Örneğin, ekran görüntüsü almak, testleri yönetmek, test sonuçlarının çıktısını almak ve daha fazlası için alternatif yöntemler kullanmalısınız.

Google IO 2016'da Google, Espresso Test Kaydedici'yi Android Studio'nun ayrılmaz bir parçası olarak tanıttı. Özellik henüz kullanıma sunulmamış olsa da kesinlikle beklemeye değecektir.

XCTest ve KIF (iOS)

XCTest, Xcode ile sıkı bir şekilde birleştirilmiştir ancak yine de hem gerçek iOS cihazları hem de simülatörler ile kullanılabilir. XCTest, geliştiricilerin herhangi bir seviyedeki bileşenler için testler yazmasına izin verir ve ayrıca UI test yetenekleri için bir çerçeve sağlar. XCTest testleri, XCTestCase'in alt sınıflarına ayrılır. XCTest ile herhangi bir test yazmak iOS geliştiricileri için önemsiz olmalıdır çünkü XCTest hem Objective-C hem de Swift ile tamamen uyumludur.

KIF ("işlevsel tut"un kısaltması), XCTest test hedefleriyle yakından ilişkili ve bunları kullanan bir iOS entegrasyon test çerçevesidir. KIF testleri, doğrudan XCTestCase veya herhangi bir alt sınıfta yürütülebilir. KIF, OS'nin görme engellilere sunduğu erişilebilirlik özelliklerinden yararlanarak iOS uygulamalarının kolay otomasyonunu sağlar.

Şimdi UI bileşenlerimizin Objective-C ile nasıl görüneceğini görelim:

 - (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }

Alternatif olarak, Swift ile test şu kadar basit görünebilir:

 testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }

Bu üst düzey sözde kodun tam olarak çalışması için ek kod gerektirdiğini unutmayın. XCTest ve genel olarak Xcode test özelliklerini kullanma hakkında daha fazla bilgi arıyorsanız, Apple her şeyi yaptınız.

EarlGrey (iOS)

Google, EarlGrey adlı işlevsel iOS uygulama test çerçevesini açık kaynaklı hale getirdiğinde bu yılın başlarındaydı. Google tarafından dahili olarak kullanıldığından, yerel iOS uygulamalarıyla (YouTube, Google Takvim, Google Fotoğraflar, Google Play Müzik) nispeten iyi çalıştı ve ciddi bir ilgi uyandırdı. EarlGrey'i kullanmaya başlamak için, yüklü Xcode ortamına ve temel iOS geliştirme bilgisine ihtiyacınız olacak.

EarlGrey ve Espresso arasında pek çok benzerlik vardır (evet, her ikisi de Google tarafından geliştirilmiştir) ve özellikleri, her iki çerçevenin de çalışmasını ve testleri hızlı bir şekilde yürütmesini sağlar. Espresso'ya benzer şekilde, EarlGrey testleri, kullanıcı arayüzü ile etkileşime girmeden önce olayları (animasyonlar, ağ istekleri vb.) otomatik olarak bekler. Bu, testlerin yazılmasını kolaylaştırır çünkü geliştiricilerin uyku veya bekleme komutları hakkında endişelenmesine gerek yoktur. Ayrıca, test adımlarının prosedürel açıklamalarını sağladığı için kodun kendisinin bakımı daha kolaydır.

EarlGrey ayrıca GREYMatchers sınıfında bulunan eşleştiricileri de içerir. Belgeler, erişilebilirlik parametreleriyle UI öğelerinin kullanılmasını önerir. UI öğelerini tanımlamak için geliştiriciler grey_accessibilityID() veya grey_accessibilityLabel() kullanabilir.

 - (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }

XCTest'e benzer şekilde, radyo düğmesi uygulamamız o kadar basit değildir ve XCTest düğmeleri, tıklamaları ve kullanıcı etkileşimlerini etkinleştirmek için iOS destekli UIElements olarak tanımlanmalıdır.

Çözüm

React Native uygulamalarının temellerini ve çeşitli yöntemler ve çerçeveler kullanılarak nasıl test edilebileceğini ele aldık. Bu oldukça sık ortaya çıkıyor, ancak işlevsel kullanıcı arayüzü düzeyinde mobil test otomasyonu için endüstri standartları, tıpkı diğer yerel uygulamalarda olduğu gibi React Native uygulamalarında da çalışacak. Burada ele aldığımız test otomasyon çerçeveleri, yerel mobil uygulamalar, hibrit uygulamalar, mobil web ve React Native uygulamaları için yaygın olarak kullanılmaktadır.

Özetle, bir mobil uygulamanın üzerine inşa edildiği programlama dilinin belirlenmesi kritik değildir çünkü test edilebileceği test-otomasyon çerçeveleri üzerinde herhangi bir etkisi olmayacaktır. Tartışıldığı gibi, günümüzde React Native uygulamalarının APK veya IPA olarak paketlendiğinde birlikte çalışacağı çok sayıda güçlü test otomasyon çerçevesi mevcuttur.

React Native uygulama testi için ne kullanıyorsunuz? Aşağıda bir yorumla tartın!