Tutorial Pengujian Android: Pengujian Unit seperti Droid Hijau Sejati

Sebagai pengembang aplikasi berpengalaman, seiring dengan matangnya aplikasi yang kami kembangkan, kami mendapat firasat bahwa inilah saatnya untuk memulai pengujian. Aturan bisnis sering menyiratkan bahwa sistem harus memberikan stabilitas di seluruh rilis yang berbeda. Kami juga idealnya ingin mengotomatiskan proses pembuatan dan memublikasikan aplikasi secara otomatis. Untuk ini, kami memerlukan alat pengujian Adnroid untuk menjamin bahwa build berfungsi seperti yang diharapkan.

Tes dapat memberikan tingkat kepercayaan ekstra tentang hal-hal yang kita bangun. Sulit (jika bukan tidak mungkin) untuk membangun produk yang sempurna dan bebas bug. Oleh karena itu, tujuan kami adalah meningkatkan peluang kami untuk berhasil di pasar dengan menyiapkan rangkaian pengujian yang akan dengan cepat menemukan bug yang baru diperkenalkan di aplikasi kami.

Ketika datang ke Android, dan berbagai platform seluler pada umumnya, pengujian aplikasi bisa menjadi tantangan. Menerapkan tes unit dan mengikuti prinsip pengembangan yang digerakkan oleh tes atau serupa sering kali terasa tidak intuitif, setidaknya. Meskipun demikian, pengujian itu penting, dan tidak boleh dianggap remeh atau diabaikan. David, Kent dan Martin telah membahas manfaat dan jebakan pengujian dalam serangkaian percakapan di antara mereka yang disusun dalam sebuah artikel berjudul "Apakah TDD mati?". Anda juga dapat menemukan percakapan video aktual di sana dan mendapatkan lebih banyak wawasan jika pengujian sesuai dengan proses pengembangan Anda dan sejauh mana Anda dapat menggabungkannya, mulai sekarang.

Dalam tutorial pengujian Android ini saya akan memandu Anda melalui unit dan penerimaan, pengujian regresi di Android. Kami akan fokus pada abstraksi unit pengujian di Android, diikuti dengan contoh pengujian penerimaan, dengan fokus membuat proses secepat dan sesederhana mungkin untuk mempersingkat siklus umpan balik QA developer.

Haruskah Saya Membacanya?

Tutorial ini akan mengeksplorasi berbagai kemungkinan dalam hal pengujian aplikasi Android. Pengembang atau manajer proyek yang ingin lebih memahami kemungkinan pengujian platform Android saat ini dapat memutuskan menggunakan tutorial ini jika mereka ingin mengambil salah satu pendekatan yang disebutkan dalam artikel ini. Namun, ini bukan peluru perak, karena diskusi yang terlibat dalam topik semacam itu secara inheren bervariasi dari produk ke produk bersama dengan tenggat waktu, kualitas kode basis kode, tingkat penggabungan sistem, preferensi pengembang dalam desain arsitektur, proyeksi umur fitur hingga tes, dll.

Berpikir dalam Satuan: Pengujian Android

Idealnya, kita ingin menguji satu unit/komponen logis dari sebuah arsitektur secara independen. Dengan cara ini kami dapat menjamin bahwa komponen kami berfungsi dengan baik untuk set input yang kami harapkan. Ketergantungan dapat diejek, yang memungkinkan kita untuk menulis tes yang dijalankan dengan cepat. Selanjutnya, kami akan dapat mensimulasikan status sistem yang berbeda berdasarkan input yang diberikan untuk pengujian, yang mencakup kasus-kasus eksotis dalam proses.

Tujuan pengujian unit Android adalah untuk mengisolasi setiap bagian dari program dan menunjukkan bahwa masing-masing bagian sudah benar. Tes unit memberikan kontrak tertulis yang ketat yang harus dipenuhi oleh potongan kode. Akibatnya, ia memberikan beberapa manfaat. —Wikipedia

Roboelektrik

Robolectric adalah kerangka kerja pengujian unit Android yang memungkinkan Anda menjalankan pengujian di dalam JVM pada stasiun kerja pengembangan Anda. Robolectric menulis ulang kelas Android SDK saat sedang dimuat dan memungkinkannya untuk berjalan pada JVM biasa, menghasilkan waktu pengujian yang cepat. Selain itu, ini menangani peningkatan tampilan, pemuatan sumber daya, dan lebih banyak hal yang diimplementasikan dalam kode C asli pada perangkat Android, membuat kebutuhan akan emulator dan perangkat fisik untuk menjalankan pengujian otomatis menjadi usang.

Mockito

Mockito adalah kerangka kerja mocking yang memungkinkan kita untuk menulis tes bersih di java. Ini menyederhanakan proses pembuatan uji ganda (tiruan), yang digunakan untuk menggantikan dependensi asli dari komponen/modul yang digunakan dalam produksi. Jawaban StackOverflow membahas tentang perbedaan antara tiruan dan rintisan dalam istilah yang cukup sederhana yang dapat Anda baca untuk mempelajari lebih lanjut.

 // 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));

Selain itu, dengan Mockito kami dapat memverifikasi apakah suatu metode telah dipanggil:

 // 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(); 

Sekarang, kita tahu bahwa kita dapat menentukan pasangan aksi-reaksi yang menentukan apa yang terjadi setelah kita menjalankan aksi tertentu pada objek/komponen yang diolok-olok. Oleh karena itu, kita dapat mengolok-olok seluruh modul aplikasi kita, dan untuk setiap kasus uji membuat modul yang diolok-olok bereaksi dengan cara yang berbeda. Cara yang berbeda akan mencerminkan kemungkinan status komponen yang diuji dan pasangan komponen yang diejek.

Pengujian Unit

Pada bagian ini, kita akan mengasumsikan arsitektur MVP (Model View Presenter). Aktivitas dan fragmen adalah tampilan, model menjadi lapisan repositori untuk panggilan ke database atau layanan jarak jauh, dan presenter menjadi "otak" yang mengikat semua ini bersama-sama menerapkan logika khusus untuk mengontrol tampilan, model, dan aliran data melalui aplikasi.

Komponen Abstrak

Tampilan dan Model yang mengejek

Dalam contoh pengujian Android ini, kami akan mengolok-olok tampilan, model, dan komponen repositori, dan kami akan menguji unit penyaji. Ini adalah salah satu tes terkecil, menargetkan satu komponen dalam arsitektur. Selanjutnya, kita akan menggunakan metode penghentian untuk menyiapkan rantai reaksi yang tepat dan dapat diuji:

 @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))); } }

Mengejek Lapisan Jaringan Global dengan MockWebServer

Seringkali nyaman untuk dapat mengejek lapisan jaringan global. MockWebServer memungkinkan kami untuk mengantrekan respons untuk permintaan spesifik yang kami jalankan dalam pengujian kami. Ini memberi kami kesempatan untuk mensimulasikan respons tidak jelas yang kami harapkan dari server, tetapi tidak mudah untuk direproduksi. Ini memungkinkan kami untuk memastikan cakupan penuh saat menulis sedikit kode tambahan.

Repositori kode MockWebServer memberikan contoh rapi yang dapat Anda rujuk untuk pemahaman yang lebih baik tentang perpustakaan ini.

Ganda Uji Kustom

Anda dapat menulis model atau komponen respoistory Anda sendiri dan memasukkannya ke dalam pengujian dengan memberikan modul berbeda ke grafik objek menggunakan Dagger (http://square.github.io/dagger/). Kami memiliki opsi untuk memeriksa apakah status tampilan telah diperbarui dengan benar berdasarkan data yang disediakan oleh komponen model tiruan:

 /** 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); } } }

Menjalankan Tes

Android Studio

Anda dapat dengan mudah mengklik kanan kelas pengujian, metode, atau seluruh paket pengujian dan menjalankan pengujian dari dialog opsi di IDE.

Terminal

Menjalankan pengujian aplikasi Android dari terminal membuat laporan untuk kelas yang diuji di folder "build" modul target. Terlebih lagi, jika Anda berencana untuk menyiapkan proses pembuatan otomatis, Anda akan menggunakan pendekatan terminal. Dengan Gradle, Anda dapat menjalankan semua pengujian rasa debug dengan menjalankan perintah berikut:

 gradle testDebug

Mengakses Source Set "test" dari Android Studio Version

Versi 1.1 Android Studio dan plugin Android Gradle memberikan dukungan untuk pengujian unit kode Anda. Anda dapat mempelajari lebih lanjut dengan membaca dokumentasi mereka yang luar biasa. Fitur ini eksperimental, tetapi juga penyertaan yang bagus karena Anda sekarang dapat dengan mudah beralih antara pengujian unit dan set sumber pengujian instrumentasi dari IDE. Ini berperilaku dengan cara yang sama seperti jika Anda akan mengganti rasa di IDE.

Mempermudah Proses

Menulis pengujian aplikasi Android mungkin tidak semenyenangkan mengembangkan aplikasi asli. Oleh karena itu, beberapa tip tentang cara memudahkan proses tes penulisan dan menghindari masalah umum saat menyiapkan proyek akan sangat membantu.

TegaskanJ Android

AssertJ Android, seperti yang mungkin sudah Anda duga dari namanya, adalah seperangkat fungsi pembantu yang dibangun dengan mempertimbangkan Android. Ini adalah ekstensi ke perpustakaan populer AssertJ. Fungsionalitas yang disediakan oleh AssertJ Android berkisar dari pernyataan sederhana, seperti “assertThat(view).isGone()”, hingga hal-hal rumit seperti:

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

Dengan AssertJ Android dan ekstensibilitasnya, Anda dijamin sebagai titik awal yang sederhana dan baik untuk menulis tes untuk aplikasi Android.

Robolectric dan Jalur Manifes

Saat menggunakan Robolectric, Anda mungkin memperhatikan bahwa Anda harus menentukan lokasi manifes, dan versi SDK disetel ke 18. Anda dapat melakukannya dengan menyertakan anotasi “Config”.

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

Menjalankan tes yang memerlukan Robolectric dari terminal dapat menimbulkan tantangan baru. Misalnya, Anda mungkin melihat pengecualian seperti "Tema tidak disetel". Jika pengujian dijalankan dengan benar dari IDE, tetapi tidak dari terminal, Anda mungkin mencoba menjalankannya dari jalur di terminal di mana jalur manifes yang ditentukan tidak dapat diselesaikan. Nilai konfigurasi hard-code untuk jalur manifes mungkin tidak menunjuk ke lokasi yang tepat dari titik eksekusi perintah. Ini dapat diselesaikan melalui penggunaan pelari khusus:

 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; } }

Konfigurasi Gradle

Anda dapat menggunakan yang berikut ini untuk mengonfigurasi Gradle untuk pengujian unit. Anda mungkin perlu mengubah nama dependensi dan versi yang diperlukan berdasarkan kebutuhan proyek Anda.

 // 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' }

Layanan Robolectric dan Play

Jika Anda menggunakan Layanan Google Play, Anda harus membuat konstanta bilangan bulat Anda sendiri untuk versi Layanan Play agar Robolectric berfungsi dengan baik dalam konfigurasi aplikasi ini.

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

Ketergantungan Robolectric untuk Mendukung Perpustakaan

Masalah pengujian menarik lainnya adalah Robolectric tidak dapat mereferensikan pustaka dukungan dengan benar. Solusinya adalah menambahkan file "project.properties" ke modul tempat pengujian berada. Misalnya, untuk pustaka Support-v4 dan AppCompat file harus berisi:

 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

Pengujian Penerimaan/Regresi

Pengujian Penerimaan/Regresi mengotomatiskan bagian dari langkah terakhir pengujian pada lingkungan Android 100% nyata. Kami tidak menggunakan kelas OS Android tiruan pada level ini - pengujian dijalankan pada perangkat dan emulator nyata.

Keadaan ini membuat proses jauh lebih tidak stabil karena variasi perangkat fisik, konfigurasi emulator, status perangkat, dan set fitur dari setiap perangkat. Selain itu, sangat bergantung pada versi sistem operasi dan ukuran layar ponsel untuk memutuskan bagaimana konten akan ditampilkan.

Agak rumit untuk membuat tes yang tepat yang lolos pada berbagai perangkat, tetapi seperti biasa Anda harus bermimpi besar namun memulai dari yang kecil. Pembuatan tes dengan Robotium adalah proses berulang. Dengan beberapa trik, itu bisa disederhanakan banyak.

Robotium

Robotium adalah kerangka kerja otomatisasi pengujian Android open source yang telah ada sejak Januari 2010. Perlu disebutkan bahwa Robotium adalah solusi berbayar, tetapi hadir dengan uji coba gratis yang adil.

Untuk mempercepat proses penulisan tes Robotium, kami akan beralih dari penulisan tes manual ke perekaman tes. Trade-off adalah antara kualitas kode dan kecepatan. Jika Anda membuat perubahan besar pada antarmuka pengguna, Anda akan mendapat banyak manfaat dari pendekatan perekaman pengujian dan kemampuan merekam pengujian baru dengan cepat.

Testdroid Recorder adalah perekam tes gratis yang membuat tes Robotium karena merekam klik yang Anda lakukan pada antarmuka pengguna. Memasang alat ini sangat mudah, seperti yang dijelaskan dalam dokumentasi mereka disertai dengan video langkah-demi-langkah.

Karena Testdroid Recorder adalah plugin Eclipse dan kami mengacu pada Android Studio di seluruh artikel ini, idealnya ini menjadi alasan perhatian. Namun, dalam hal ini tidak menjadi masalah, karena Anda dapat menggunakan plugin secara langsung dengan APK dan merekam pengujian terhadapnya.

Setelah membuat pengujian, Anda dapat menyalin dan menempelkannya di Android Studio, bersama dengan ketergantungan apa pun yang diperlukan perekam Testdroid, dan Anda siap melakukannya. Tes yang direkam akan terlihat seperti kelas di bawah ini:

 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; } } }

Jika Anda melihat lebih dekat, Anda akan melihat berapa banyak kode yang agak lurus ke depan.

Saat merekam tes, jangan menggunakan pernyataan "tunggu". Tunggu dialog muncul, aktivitas muncul, teks muncul. Ini akan menjamin bahwa aktivitas dan hierarki tampilan siap untuk berinteraksi saat Anda melakukan tindakan di layar saat ini. Pada saat yang sama, ambil tangkapan layar. Pengujian otomatis biasanya tanpa pengawasan, dan tangkapan layar adalah salah satu cara untuk melihat apa yang sebenarnya terjadi selama pengujian tersebut.

Apakah tes lulus atau gagal, laporan adalah teman terbaik Anda. Anda dapat menemukannya di bawah direktori build “module/build/outputs/reports”:

Secara teori, tim QA dapat merekam pengujian dan mengoptimalkannya. Dengan menempatkan upaya dalam model standar untuk mengoptimalkan kasus uji, itu bisa dilakukan. Ketika Anda biasanya merekam tes, Anda selalu harus mengubah beberapa hal untuk membuatnya bekerja dengan sempurna.

Terakhir, untuk menjalankan pengujian ini dari Android Studio, Anda dapat memilihnya dan menjalankannya seperti menjalankan pengujian unit. Dari terminal, ini adalah satu baris:

 gradle connectedAndroidTest

Kinerja Pengujian

Pengujian unit Android dengan Robolectric sangat cepat, karena dijalankan langsung di dalam JVM di mesin Anda. Dibandingkan dengan itu, pengujian penerimaan pada emulator dan perangkat fisik jauh lebih lambat. Bergantung pada ukuran aliran yang Anda uji, ini bisa memakan waktu mulai dari beberapa detik hingga beberapa menit per kasus pengujian. Fase uji penerimaan harus digunakan sebagai bagian dari proses pembuatan otomatis pada server integrasi berkelanjutan.

Kecepatan dapat ditingkatkan dengan paralelisasi pada beberapa perangkat. Lihat alat hebat ini dari Jake Wharton dan orang-orang di Square http://square.github.io/spoon/. Ini memiliki beberapa pelaporan yang bagus juga.

Bawa Pulang

Ada berbagai alat pengujian Android yang tersedia, dan seiring dengan matangnya ekosistem, proses menyiapkan lingkungan yang dapat diuji dan menulis pengujian akan menjadi lebih mudah. Masih ada lebih banyak tantangan untuk diatasi, dan dengan komunitas pengembang yang luas yang mengerjakan masalah sehari-hari, ada banyak ruang untuk diskusi konstruktif dan umpan balik yang cepat.

Gunakan pendekatan yang dijelaskan dalam tutorial pengujian Android ini untuk memandu Anda dalam mengatasi tantangan di depan Anda. Jika dan ketika Anda mengalami masalah, periksa kembali dengan artikel ini atau referensi yang ditautkan di dalam untuk solusi masalah yang diketahui.

Dalam posting mendatang, kita akan membahas paralelisasi, otomatisasi build, integrasi berkelanjutan, kait Github/BitBucket, versi artefak, dan praktik terbaik untuk mengelola proyek aplikasi seluler besar secara lebih mendalam.