WHY + HOW OF ANDROID TESTING CODE WITHOUT TEST IS BAD CODE 

Hello Su Myat Lead Android Developer Wave Money Twitter : @SuMyatHtun9 Women Teachmakers Ambassador Currently teaching myself Kotlin 

OVERVIEW What we’ll talk about today 1.Importance: the problem with the way we build apps and why your current approach will tire you out 2.Automated Testing: how to write automated test script 3.Android Testing in Action: let’s get our hands dirty ;) 

I: 
 Importance 

WHY ANDROID TESTING WILL MAKE YOUR LIFE EASIER The problem with how we do things now ‣ We are building application that are unnecessarily complex. ‣ We have to test that previous features working properly. ‣ Doing this manually every time is tiring. It makes you prone to mistakes and does not scale 

II: Automated Testing 

WHERE TO START? How of Automated Testing ‣ Great at scaling and automating ‣ Do not require to manually operate the app to verify the code works. ‣ You need to consider these factors (Scope, Speed, Fidelity) when planning your tests ‣ Scope: How much of the code does the test touch? ‣ Speed: How fast do you want your test to run? Do you want it to take minutes or milliseconds? ‣ Fidelity: How close to the real world do you want your tests to be? ‣ Once you’ve defined scope, speed and fidelity, you’re ready to start writing test scripts (E2E, Integration, Unit) 

THE TESTING PYRAMID https://codelabs.developers.google.com/codelabs/android-testing/#2 

STEP3 In android testing ‣ Unit Testing: It’s fast, lightweight, get high scalability. And It’s a single method and single test. ‣ Integrated Testing: The interaction of several classes to make sure they behave as expected when used together ‣ EndtoEnd Testing: Automated scripts that run through an entire user’s journey on your application. Tests verify the proper operation of app using as many real components. It’s slower that integration test and unit test but that gave you confidence the app works as a whole. 

NOW THAT YOU’RE READY TO START BUILDING Requirements for android testing ‣ It’s important that your application is architected for testability ‣ Extremely poor-architecture application might pull of its logic inside one method which makes it difficult to test a single unit or feature. ‣ A better approach would be to break down the app logic into multiple methods and class, allowing each piece to be tested in insolation. 

III: Android Testing in Action 

What you’ll need: Go to the following link, and access the sample project I created in GitHub : https://bit.ly/2Yzy09K Reference : link from google: https:// codelabs.developers.google.com/codelabs/android-testing/#0 

CRITICAL USER JOURNEY 

ARCHITECTURE COMPONENTS NotesActivity AddNoteFragment NotesFragment AddNoteViewModel NotesViewModel Repository LocalDataStore ViewModel View Model Navigation Data Binding Live Data Room 

MODULAR APPLICATION Show Notes CLASS CLASS CLASS UNIT TEST E2E TEST INTEGRATION TEST Add Note CLASS CLASS 

END TO END TEST TaskActivity AddTaskFragment TasksFragment AddTaskViewModel TasksViewModel Repository LocalDataStore TasksDao SQLite Tests verify the proper operation of app using as many real components. It’s slower that integration test and unit test but that gave you confidence the app works as a whole. 

@Before fun init() { repository = ServiceLocator.provideTasksRepository(ApplicationProvider.getApplicationContext()) } @After fun reset() { ServiceLocator.resetRepository() } @Test fun saveTask(){ //save note first repository.saveNoteBlocking(Note("TITLE1", "DESCRIPTION")) // start up Notes screen val activityScenario = ActivityScenario.launch(NotesActivity::class.java) dataBindingIdlingResource.monitorActivity(activityScenario) // Verify note is displayed Espresso.onView(ViewMatchers.withText(“TITLE1")).check(ViewAssertions.matches (ViewMatchers.isDisplayed())) // Verify previous note is not displayed Espresso.onView(ViewMatchers.withText(“TITLE")).check(ViewAssertions.doesNotExist() } 

INTEGRATION TEST It’s a blurred line between integration and unit tests. You can test with real object, fake, stub and dummy. AddTaskFragment AddTaskViewModel Repository LocalDataStore TasksDao SQLite 

@Test fun validTask_isSaved() { // GIVEN - On the "Add Note" screen. val navController = Mockito.mock(NavController::class.java) launchFragment(navController) // WHEN - Valid title and description combination and click save Espresso.onView(ViewMatchers.withId(R.id.add_task_title)).perform(ViewActions.replac eText("title")) Espresso.onView(ViewMatchers.withId(R.id.add_task_description)).perform(ViewActions. replaceText("description")) Espresso.onView(ViewMatchers.withId(R.id.fab_save_task)).perform(ViewActions.click() ) // THEN - Verify that the repository saved the task val tasks = (repository.getNotesBlocking() as Result.Success).data Assert.assertEquals(tasks.size, 1) Assert.assertEquals(tasks[0].title, "title") Assert.assertEquals(tasks[0].description, "description") } 

UNIT TEST Tests that should run in milliseconds and a big project will have thousands of them and gave very fast feedback on failures. Room TestDatabase SQLite TaskLocalDataStore TaskDao Mockito 

@Before fun setupViewModel() { repo = FakeRepository() viewmodel = AddNoteViewModel(repo) } @ObsoleteCoroutinesApi @Test fun saveTask(){ val newTitle = "New Note Title" val newDescription = "Some Note Description" viewmodel.saveNote(newTitle, newDescription) // Execute pending coroutines actions testContext.triggerActions() val newTask = repo.tasksServiceData.values.first() // Then a note is saved in the repository and the view updated assertThat(newTask.title).isEqualTo(newTitle) assertThat(newTask.description).isEqualTo(newDescription) } 

- Automated testing on Android may seem intimidating, but in the long run it will save you from many headaches. - Before you jump into automated testing, ask yourself: is my architecture simplified and ‘testable’? Have I defined the scope, speed and fidelity of the tests I want to run? - Keep learning: https:// codelabs.developers.google.com/codelabs/android- testing/#0 Key Takeaways 

thank y u.