Android Test Eğitimi: Gerçek Yeşil Droid Gibi Birim Testi

Deneyimli uygulama geliştiricileri olarak, geliştirdiğimiz uygulamalar olgunlaştıkça, teste başlama zamanının geldiğine dair içimize bir his geliyor. İş kuralları genellikle sistemin farklı sürümler boyunca kararlılık sağlaması gerektiğini ima eder. Ayrıca ideal olarak oluşturma sürecini otomatikleştirmek ve uygulamayı otomatik olarak yayınlamak istiyoruz. Bunun için, yapının beklendiği gibi çalıştığını garanti etmek için Adnroid test araçlarına ihtiyacımız var.

Testler, inşa ettiğimiz şeyler hakkında ekstra güven düzeyi sağlayabilir. Kusursuz, hatasız bir ürün oluşturmak zordur (imkansız değilse de). Bu nedenle amacımız, uygulamamızda yeni tanıtılan hataları hızla tespit edecek bir test paketi kurarak piyasada başarılı olma olasılığımızı artırmak olacaktır.

Android ve genel olarak çeşitli mobil platformlar söz konusu olduğunda, uygulama testi zor olabilir. Birim testleri uygulamak ve test odaklı geliştirme veya benzeri ilkeleri takip etmek, en azından çoğu zaman sezgisel olmayabilir. Bununla birlikte, test önemlidir ve hafife alınmamalı veya göz ardı edilmemelidir. David, Kent ve Martin, “TDD öldü mü?” başlıklı bir makalede derlenen kendi aralarında bir dizi konuşmada test etmenin yararlarını ve tuzaklarını tartıştılar. Ayrıca, gerçek görüntülü konuşmaları orada bulabilir ve testin geliştirme sürecinize uygun olup olmadığı ve şimdiden başlayarak bunu ne ölçüde dahil edebileceğiniz konusunda daha fazla bilgi edinebilirsiniz.

Bu Android test eğitiminde, Android'de birim ve kabul, regresyon testi konusunda size yol göstereceğim. Geliştirici-QA geri bildirim döngülerini kısaltmak için süreci olabildiğince hızlı ve basit hale getirmeye odaklanarak, Android'deki test biriminin soyutlanmasına ve ardından kabul testi örneklerine odaklanacağız.

Okumalı mıyım?

Bu eğitim, Android uygulamalarını test etme söz konusu olduğunda farklı olasılıkları keşfedecektir. Android platformunun mevcut test olanaklarını daha iyi anlamak isteyen geliştiriciler veya proje yöneticileri, bu makalede bahsedilen yaklaşımlardan herhangi birini almak isterlerse bu öğreticiyi kullanmaya karar verebilirler. Bununla birlikte, bu bir gümüş kurşun değildir, çünkü böyle bir konuyla ilgili tartışma, son tarihler, kod tabanı kalitesi, sistemin bağlantı düzeyi, geliştiricinin mimari tasarımdaki tercihi, özelliğin öngörülen ömrü ile birlikte üründen ürüne doğal olarak farklılık gösterir. testi, vb.

Birimlerde Düşünme: Android Testi

İdeal olarak, bir mimarinin bir mantıksal birimini/bileşenini bağımsız olarak test etmek istiyoruz. Bu şekilde, bileşenimizin beklediğimiz girdi kümesi için düzgün çalıştığını garanti edebiliriz. Bağımlılıklarla alay edilebilir, bu da hızlı çalışan testler yazmamızı sağlar. Ayrıca, süreçteki egzotik durumları kapsayan, teste sağlanan girdiye dayalı olarak farklı sistem durumlarını simüle edebileceğiz.

Android birim testinin amacı, programın her bir bölümünü izole etmek ve tek tek bölümlerin doğru olduğunu göstermektir. Birim testi, kod parçasının karşılaması gereken katı, yazılı bir sözleşme sağlar. Sonuç olarak, çeşitli faydalar sağlar. —Vikipedi

robotik

Robolectric, geliştirme iş istasyonunuzda JVM içinde testler çalıştırmanıza izin veren bir Android birim test çerçevesidir. Robolectric, Android SDK sınıflarını yüklenirken yeniden yazar ve normal bir JVM üzerinde çalışmalarını mümkün kılar, bu da hızlı test süreleriyle sonuçlanır. Ayrıca, Android cihazlarda yerel C kodunda uygulanan görünümlerin şişmesini, kaynak yüklemeyi ve daha fazlasını işleyerek, otomatikleştirilmiş testleri çalıştırmak için öykünücülere ve fiziksel aygıtlara olan ihtiyacı ortadan kaldırır.

Mockito

Mockito, Java'da temiz testler yazmamızı sağlayan alaycı bir çerçevedir. Üretimde kullanılan bir bileşenin/modülün orijinal bağımlılıklarını değiştirmek için kullanılan test çiftleri (sahteler) oluşturma sürecini basitleştirir. Bir StackOverflow yanıtı, daha fazlasını öğrenmek için okuyabileceğiniz oldukça basit terimlerle alaylar ve taslaklar arasındaki farkları tartışır.

 // you can mock concrete classes, not only interfaces LinkedList mockedList = mock(LinkedList.class); // stubbing appears before the actual execution when(mockedList.get(0)).thenReturn("first"); // the following prints "first" System.out.println(mockedList.get(0)); // the following prints "null" because get(999) was not stubbed System.out.println(mockedList.get(999));

Ek olarak, Mockito ile bir yöntemin çağrıldığını doğrulayabiliriz:

 // mock creation List mockedList = mock(List.class); // using mock object - it does not throw any "unexpected interaction" exception mockedList.add("one"); mockedList.clear(); // selective, explicit, highly readable verification verify(mockedList).add("one"); verify(mockedList).clear(); 

Artık, alay konusu nesne/bileşen üzerinde belirli bir eylemi gerçekleştirdiğimizde ne olacağını tanımlayan eylem-tepki çiftlerini belirleyebileceğimizi biliyoruz. Bu nedenle, uygulamamızın tüm modüllerini alay edebilir ve her test durumu için alaylı modülün farklı bir şekilde tepki vermesini sağlayabiliriz. Farklı yollar, test edilen bileşen ve sahte bileşen çiftinin olası durumlarını yansıtacaktır.

Birim Testi

Bu bölümde MVP (Model View Presenter) mimarisini ele alacağız. Aktiviteler ve parçalar görünümler, veritabanına veya uzak hizmetlere yapılan çağrılar için depo katmanı olan modeller ve tüm bunları birbirine bağlayan “beyin” olan sunumcu, görünümleri, modelleri ve veri akışını kontrol etmek için belirli bir mantık uygular. başvuru.

Soyutlama Bileşenleri

Alaycı Görünümler ve Modeller

Bu Android test örneğinde, görünümler, modeller ve veri havuzu bileşenleriyle alay edeceğiz ve sunucuyu birim testi yapacağız. Bu, mimarideki tek bir bileşeni hedefleyen en küçük testlerden biridir. Ayrıca, uygun, test edilebilir bir reaksiyon zinciri oluşturmak için saplama yöntemini kullanacağız:

 @RunWith(RobolectricTestRunner.class) @Config(manifest = "app/src/main/AndroidManifest.xml", emulateSdk = 18) public class FitnessListPresenterTest { private Calendar cal = Calendar.getInstance(); @Mock private IFitnessListModel model; @Mock private IFitnessListView view; private IFitnessListPresenter presenter; @Before public void setup() { MockitoAnnotations.initMocks(this); final FitnessEntry entryMock = mock(FitnessEntry.class); presenter = new FitnessListPresenter(view, model); /* Define the desired behaviour. Queuing the action in "doAnswer" for "when" is executed. Clear and synchronous way of setting reactions for actions (stubbing). */ doAnswer((new Answer<Object>() { @Override public Object answer(InvocationOnMock invocation) throws Throwable { ArrayList<FitnessEntry> items = new ArrayList<>(); items.add(entryMock); ((IFitnessListPresenterCallback) presenter).onFetchAllSuccess(items); return null; } })).when(model).fetchAllItems((IFitnessListPresenterCallback) presenter); } /** Verify if model.fetchItems was called once. Verify if view.onFetchSuccess is called once with the specified list of type FitnessEntry The concrete implementation of ((IFitnessListPresenterCallback) presenter).onFetchAllSuccess(items); calls the view.onFetchSuccess(...) method. This is why we verify that view.onFetchSuccess is called once. */ @Test public void testFetchAll() { presenter.fetchAllItems(false); // verify can be called only on mock objects verify(model, times(1)).fetchAllItems((IFitnessListPresenterCallback) presenter); verify(view, times(1)).onFetchSuccess(new ArrayList<>(anyListOf(FitnessEntry.class))); } }

MockWebServer ile Global Ağ Katmanı ile Alay Etmek

Küresel ağ katmanıyla alay edebilmek genellikle uygundur. MockWebServer, testlerimizde yürüttüğümüz belirli istekler için yanıtları sıraya koymamıza olanak tanır. Bu bize sunucudan beklediğimiz, ancak yeniden üretilmesi kolay olmayan belirsiz yanıtları simüle etme şansı verir. Küçük ek kod yazarken tam kapsama sağlamamızı sağlar.

MockWebServer'ın kod deposu, bu kitaplığı daha iyi anlamak için başvurabileceğiniz güzel bir örnek sunar.

Özel Test Çiftleri

Dagger (http://square.github.io/dagger/) kullanarak nesne grafiğine farklı bir modül sağlayarak kendi modelinizi veya depo bileşeninizi yazıp teste enjekte edebilirsiniz. Sahte model bileşeni tarafından sağlanan verilere dayanarak görünüm durumunun düzgün bir şekilde güncellenip güncellenmediğini kontrol etme seçeneğine sahibiz:

 /** Custom mock model class */ public class FitnessListErrorTestModel extends FitnessListModel { // ... @Override public void fetchAllItems(IFitnessListPresenterCallback callback) { callback.onError(); } @Override public void fetchItemsInRange(final IFitnessListPresenterCallback callback, DateFilter filter) { callback.onError(); } }

 @RunWith(RobolectricTestRunner.class) @Config(manifest = "app/src/main/AndroidManifest.xml", emulateSdk = 18) public class FitnessListPresenterDaggerTest { private FitnessActivity activity; private FitnessListFragment fitnessListFragment; @Before public void setup() { /* setupActivity runs the Activity lifecycle methods on the specified class */ activity = Robolectric.setupActivity(FitnessActivity.class); fitnessListFragment = activity.getFitnessListFragment(); /* Create the objectGraph with the TestModule */ ObjectGraph localGraph = ObjectGraph.create(TestModule.newInstance(fitnessListFragment)); /* Injection */ localGraph.inject(fitnessListFragment); localGraph.inject(fitnessListFragment.getPresenter()); } @Test public void testInteractorError() { fitnessListFragment.getPresenter().fetchAllItems(false); /* suppose that our view shows a Toast message with the specified text below when an error is reported, so we check for it. */ assertEquals(ShadowToast.getTextOfLatestToast(), "Something went wrong!"); } @Module( injects = { FitnessListFragment.class, FitnessListPresenter.class }, overrides = true, library = true ) static class TestModule { private IFitnessListView view; private TestModule(IFitnessListView view){ this.view = view; } public static TestModule newInstance(IFitnessListView view){ return new TestModule(view); } @Provides public IFitnessListInteractor provideFitnessListInteractor(){ return new FitnessListErrorTestModel(); } @Provides public IFitnessListPresenter provideFitnessPresenter(){ return new FitnessListPresenter(view); } } }

Testleri Çalıştırma

Android Stüdyosu

Bir test sınıfını, yöntemini veya tüm test paketini kolayca sağ tıklayıp IDE'deki seçenekler iletişim kutusundan testleri çalıştırabilirsiniz.

terminal

Android uygulama testlerini terminalden çalıştırmak, hedef modülün "build" klasöründe test edilen sınıflar için raporlar oluşturur. Dahası, otomatik bir inşa süreci kurmayı planlıyorsanız, terminal yaklaşımını kullanacaksınız. Gradle ile, aşağıdakileri yürüterek tüm hata ayıklama aromalı testleri çalıştırabilirsiniz:

 gradle testDebug

Android Studio Sürümünden Kaynak Kümesi “testine” erişme

Android Studio'nun 1.1 Sürümü ve Android Gradle eklentisi, kodunuzu birim testi için destek sağlar. Bununla ilgili mükemmel belgelerini okuyarak daha fazlasını öğrenebilirsiniz. Bu özellik deneyseldir, ancak artık IDE'den birim testleriniz ve enstrümantasyon test kaynak setleriniz arasında kolayca geçiş yapabileceğiniz için harika bir dahil etme özelliğidir. IDE'de lezzetleri değiştiriyormuşsunuz gibi davranır.

Süreci Kolaylaştırmak

Android uygulama testleri yazmak, orijinal uygulamayı geliştirmek kadar eğlenceli olmayabilir. Bu nedenle, test yazma sürecini nasıl kolaylaştıracağınıza ve projeyi kurarken sık karşılaşılan sorunlardan nasıl kaçınacağınıza dair bazı ipuçları çok yardımcı olacaktır.

AssertJ Android

AssertJ Android, adından da tahmin edebileceğiniz gibi, Android düşünülerek oluşturulmuş bir dizi yardımcı işlevdir. Popüler AssertJ kütüphanesinin bir uzantısıdır. AssertJ Android tarafından sağlanan işlevsellik, "assertThat(view).isGone()" gibi basit iddialardan aşağıdaki gibi karmaşık şeylere kadar çeşitlilik gösterir:

 assertThat(layout).isVisible() .isVertical() .hasChildCount(4) .hasShowDividers(SHOW_DIVIDERS_MIDDLE)

AssertJ Android ve genişletilebilirliği ile Android uygulamaları için testler yazmak için basit ve iyi bir başlangıç ​​noktası garanti edilir.

Robolectric ve Manifest Yolu

Robolectric kullanırken, manifest konumunu belirtmeniz gerektiğini ve SDK sürümünün 18 olarak ayarlandığını fark edebilirsiniz. Bunu bir “Config” notu ekleyerek yapabilirsiniz.

 @Config(manifest = "app/src/main/AndroidManifest.xml", emulateSdk = 18)

Terminalden Robolectric gerektiren testler yapmak yeni zorluklar getirebilir. Örneğin, "Tema ayarlanmadı" gibi istisnalar görebilirsiniz. Testler IDE'den düzgün bir şekilde yürütülüyor ancak terminalden yürütülmüyorsa, terminalde belirtilen bildirim yolunun çözümlenemediği bir yoldan çalıştırmayı deniyor olabilirsiniz. Bildirim yolu için sabit kodlanmış yapılandırma değeri, komutun yürütüldüğü noktadan doğru konumu göstermiyor olabilir. Bu, özel koşucular kullanılarak çözülebilir:

 public class RobolectricGradleTestRunner extends RobolectricTestRunner { public RobolectricGradleTestRunner(Class<?> testClass) throws InitializationError { super(testClass); } @Override protected AndroidManifest getAppManifest(Config config) { String appRoot = "../app/src/main/"; String manifestPath = appRoot + "AndroidManifest.xml"; String resDir = appRoot + "res"; String assetsDir = appRoot + "assets"; AndroidManifest manifest = createAppManifest(Fs.fileFromPath(manifestPath), Fs.fileFromPath(resDir), Fs.fileFromPath(assetsDir)); return manifest; } }

Gradle Yapılandırması

Birim testi için Gradle'ı yapılandırmak için aşağıdakileri kullanabilirsiniz. Proje gereksinimlerinize göre gereken bağımlılık adlarını ve sürümlerini değiştirmeniz gerekebilir.

 // Robolectric testCompile 'junit:junit:4.12' testCompile 'org.mockito:mockito-core:1.9.5' testCompile 'com.squareup.dagger:dagger:1.2.2' testProvided 'com.squareup.dagger:dagger-compiler:1.2.2' testCompile 'com.android.support:support-v4:21.0.+' testCompile 'com.android.support:appcompat-v7:21.0.3' testCompile('org.robolectric:robolectric:2.4') { exclude module: 'classworlds' exclude module: 'commons-logging' exclude module: 'httpclient' exclude module: 'maven-artifact' exclude module: 'maven-artifact-manager' exclude module: 'maven-error-diagnostics' exclude module: 'maven-model' exclude module: 'maven-project' exclude module: 'maven-settings' exclude module: 'plexus-container-default' exclude module: 'plexus-interpolation' exclude module: 'plexus-utils' exclude module: 'wagon-file' exclude module: 'wagon-http-lightweight' exclude module: 'wagon-provider-api' }

Roboelektrik ve Oyun Hizmetleri

Google Play Hizmetlerini kullanıyorsanız, Robolectric'in bu uygulama yapılandırmasında düzgün çalışması için Play Hizmetleri sürümü için kendi tamsayı sabitinizi oluşturmanız gerekecektir.

 <meta-data android:name="com.google.android.gms.version" android:value="@integer/gms_version" tools:replace="android:value" />

Kütüphaneleri Desteklemek için Roboelektrik Bağımlılıklar

Bir başka ilginç test sorunu, Robolectric'in destek kitaplıklarına düzgün bir şekilde başvuramamasıdır. Çözüm, testlerin bulunduğu modüle bir “project.properties” dosyası eklemektir. Örneğin, Support-v4 ve AppCompat kitaplıkları için dosya şunları içermelidir:

 android.library.reference.1=../../build/intermediates/exploded-aar/com.android.support/support-v4/21.0.3 android.library.reference.2=../../build/intermediates/exploded-aar/com.android.support/appcompat-v7/21.0.3

Kabul/Regresyon Testi

Kabul/Regresyon testi, gerçek, yüzde 100 Android ortamında test etmenin son adımının bir bölümünü otomatikleştirir. Bu seviyede sahte Android işletim sistemi sınıfları kullanmıyoruz - testler gerçek cihazlarda ve emülatörlerde çalıştırılıyor.

Bu koşullar, fiziksel aygıtların, öykünücü yapılandırmalarının, aygıt durumlarının ve her aygıtın özellik kümelerinin çeşitliliği nedeniyle süreci çok daha kararsız hale getirir. Ayrıca, içeriğin nasıl görüntüleneceğine karar vermek büyük ölçüde işletim sisteminin sürümüne ve telefonun ekran boyutuna bağlıdır.

Çok çeşitli cihazlarda geçen doğru testi oluşturmak biraz karmaşıktır, ancak her zaman olduğu gibi büyük hayaller kurmalı, ancak küçük başlamalısınız. Robotium ile testlerin oluşturulması yinelemeli bir süreçtir. Birkaç hile ile çok basitleştirilebilir.

robotyum

Robotium, Ocak 2010'dan beri var olan açık kaynaklı bir Android test otomasyonu çerçevesidir. Robotium'un ücretli bir çözüm olduğunu, ancak adil bir ücretsiz deneme ile geldiğini belirtmekte fayda var.

Robotium testleri yazma sürecini hızlandırmak için manuel test yazmadan test kaydına geçeceğiz. Takas, kod kalitesi ve hız arasındadır. Kullanıcı arayüzünüzde yoğun değişiklikler yapıyorsanız, test kaydetme yaklaşımından ve yeni testleri hızlı bir şekilde kaydedebilmenizden çok yararlanacaksınız.

Testdroid Recorder, kullanıcı arayüzünde gerçekleştirdiğiniz tıklamaları kaydederken Robotium testleri oluşturan ücretsiz bir test kaydedicidir. Aracın kurulumu, adım adım video eşliğinde belgelerinde açıklandığı gibi son derece kolaydır.

Testdroid Recorder bir Eclipse eklentisi olduğundan ve bu makale boyunca Android Studio'ya atıfta bulunduğumuzdan, ideal olarak bir endişe nedeni olacaktır. Ancak, eklentiyi doğrudan bir APK ile kullanabileceğiniz ve buna karşı testleri kaydedebileceğiniz için bu durumda sorun olmaz.

Testleri oluşturduktan sonra, Testdroid kaydedicinin gerektirdiği herhangi bir bağımlılıkla birlikte bunları Android Studio'ya kopyalayıp yapıştırabilirsiniz ve artık hazırsınız. Kaydedilen test aşağıdaki sınıfa benzeyecektir:

 public class LoginTest extends ActivityInstrumentationTestCase2<Activity> { private static final String LAUNCHER_ACTIVITY_CLASSNAME = "com.toptal.fitnesstracker.view.activity.SplashActivity"; private static Class<?> launchActivityClass; static { try { launchActivityClass = Class.forName(LAUNCHER_ACTIVITY_CLASSNAME); } catch (ClassNotFoundException e) { throw new RuntimeException(e); } } private ExtSolo solo; @SuppressWarnings("unchecked") public LoginTest() { super((Class<Activity>) launchActivityClass); } // executed before every test method @Override public void setUp() throws Exception { super.setUp(); solo = new ExtSolo(getInstrumentation(), getActivity(), this.getClass() .getCanonicalName(), getName()); } // executed after every test method @Override public void tearDown() throws Exception { solo.finishOpenedActivities(); solo.tearDown(); super.tearDown(); } public void testRecorded() throws Exception { try { assertTrue( "Wait for edit text (id: com.toptal.fitnesstracker.R.id.login_username_input) failed.", solo.waitForEditTextById( "com.toptal.fitnesstracker.R.id.login_username_input", 20000)); solo.enterText( (EditText) solo .findViewById("com.toptal.fitnesstracker.R.id.login_username_input"), "[email protected]"); solo.sendKey(ExtSolo.ENTER); solo.sleep(500); assertTrue( "Wait for edit text (id: com.toptal.fitnesstracker.R.id.login_password_input) failed.", solo.waitForEditTextById( "com.toptal.fitnesstracker.R.id.login_password_input", 20000)); solo.enterText( (EditText) solo .findViewById("com.toptal.fitnesstracker.R.id.login_password_input"), "123456"); solo.sendKey(ExtSolo.ENTER); solo.sleep(500); assertTrue( "Wait for button (id: com.toptal.fitnesstracker.R.id.parse_login_button) failed.", solo.waitForButtonById( "com.toptal.fitnesstracker.R.id.parse_login_button", 20000)); solo.clickOnButton((Button) solo .findViewById("com.toptal.fitnesstracker.R.id.parse_login_button")); assertTrue("Wait for text fitness list activity.", solo.waitForActivity(FitnessActivity.class)); assertTrue("Wait for text KM.", solo.waitForText("KM", 20000)); /* Custom class that enables proper clicking of ActionBar action items */ TestUtils.customClickOnView(solo, R.id.action_logout); solo.waitForDialogToOpen(); solo.waitForText("OK"); solo.clickOnText("OK"); assertTrue("waiting for ParseLoginActivity after logout", solo.waitForActivity(ParseLoginActivity.class)); assertTrue( "Wait for button (id: com.toptal.fitnesstracker.R.id.parse_login_button) failed.", solo.waitForButtonById( "com.toptal.fitnesstracker.R.id.parse_login_button", 20000)); } catch (AssertionFailedError e) { solo.fail( "com.example.android.apis.test.Test.testRecorded_scr_fail", e); throw e; } catch (Exception e) { solo.fail( "com.example.android.apis.test.Test.testRecorded_scr_fail", e); throw e; } } }

Yakından bakarsanız, kodun ne kadarının oldukça basit olduğunu fark edeceksiniz.

Testleri kaydederken, “bekle” ifadelerine fazla takılmayın. Diyalogların görünmesini, etkinliklerin görünmesini, metinlerin görünmesini bekleyin. Bu, eylemi geçerli ekranda gerçekleştirdiğinizde, etkinliğin ve görünüm hiyerarşisinin etkileşime hazır olmasını garanti eder. Aynı zamanda ekran görüntüsü alın. Otomatik testler genellikle gözetimsizdir ve ekran görüntüleri, bu testler sırasında gerçekte ne olduğunu görmenin yollarından biridir.

Testler ister başarılı ister başarısız olsun, raporlar en iyi arkadaşınızdır. Bunları “module/build/outputs/reports” yapı dizini altında bulabilirsiniz:

Teorik olarak, QA ekibi testleri kaydedebilir ve optimize edebilir. Test senaryolarını optimize etmek için standartlaştırılmış bir modele çaba harcayarak yapılabilir. Normalde testleri kaydettiğinizde, kusursuz çalışması için her zaman birkaç şeyi ayarlamanız gerekir.

Son olarak, bu testleri Android Studio'dan çalıştırmak için bunları seçip birim testleri çalıştırdığınız gibi çalıştırabilirsiniz. Terminalden, tek astarlıdır:

 gradle connectedAndroidTest

Test Performansı

Robolectric ile Android birim testi son derece hızlıdır, çünkü doğrudan makinenizdeki JVM içinde çalışır. Bununla karşılaştırıldığında, öykünücüler ve fiziksel cihazlarda kabul testi çok daha yavaştır. Test ettiğiniz akışların boyutuna bağlı olarak, test senaryosu başına birkaç saniyeden birkaç dakikaya kadar sürebilir. Kabul testi aşaması, sürekli bir tümleştirme sunucusunda otomatik oluşturma sürecinin bir parçası olarak kullanılmalıdır.

Hız, birden fazla cihazda paralelleştirme ile artırılabilir. Jake Wharton ve Square http://square.github.io/spoon/ adresindeki adamların sunduğu bu harika araca göz atın. Güzel raporları da var.

Götürmek

Çeşitli Android test araçları mevcuttur ve ekosistem olgunlaştıkça test edilebilir bir ortam oluşturma ve test yazma süreci daha kolay hale gelecektir. Hala üstesinden gelinmesi gereken daha çok zorluk var ve günlük problemler üzerinde çalışan geniş bir geliştirici topluluğuyla, yapıcı tartışmalar ve hızlı geri bildirim için çok yer var.

Önünüzdeki zorluklarla başa çıkmada size rehberlik etmesi için bu Android test eğitiminde açıklanan yaklaşımları kullanın. Sorunla karşılaşırsanız, bilinen sorunların çözümleri için bu makaleyi veya içinde bağlantılı referansları tekrar kontrol edin.

Gelecekteki bir gönderide paralelleştirme, yapı otomasyonu, sürekli entegrasyon, Github/BitBucket kancaları, yapay sürüm oluşturma ve büyük mobil uygulama projelerini daha derinlemesine yönetmek için en iyi uygulamaları tartışacağız.