Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Lesson learned from Android testing

Lesson learned from Android testing

38ce08a16de0e33afbab8fd46b91cb2a?s=128

Yolanda Septiana

May 01, 2021
Tweet

Transcript

  1. Lessons learned from Android testing Yolanda Septiana Sr. Android App

    Developer @ Mitra Bukalapak 3 principles to remember
  2. The Art of Unit Testing XUnit Test Patterns: Refactoring Test

    Code
  3. What is a unit • A unit is a not

    function • It is a unit of work • Can span from a single method to multiple classes to achieve its purpose
  4. Example 1. Given user open app 2. Then user click

    Mulai button 3. And user see non-login home page 4. Then user click Masuk button 5. And user see phone number page 6. And user fill phone number "<invalid_phone_number>" field 7. And user click Lanjut button 8. Then user see "Format salah." warning on header 1. Given user open app 2. Then user click Mulai button 3. And user see non-login home page 4. Then user click Masuk button 5. And user see phone number page 6. And user fill phone number "<invalid_phone_number>" field 7. And user click Lanjut button 8. Then user see "Format salah." warning on header
  5. Espresso @RunWith(AndroidJUnit4::class) class LoginTest { ... @Test fun userLoginWrongNumber_shouldShowWarning() {

    inputFieldView().perform(typeText("54321")) buttonView().perform(click()) warningHeaderView().check(matches(isDisplayed())) } }
  6. Unit of work • Does not only apply for UI

    (Espresso) test. • It is a principle for every type code: use cases, managers, utils, handlers. • Create larger unit test, not smaller
  7. Unit of work • Avoids the habit of leaking implementation

    details, ex: testing private methods. • Private function should stay private.
  8. Unit of work • Fewer test cases, same coverage. •

    More maintainable. @Test fun firstUsecase() {} @Test fun secondUsecase() {}
  9. Front-door • Test ViewModel & business logic through the UI

    using FragmentScenario / ActivityScenario + Espresso. • Espresso test recorder. • More confident of our tests.
  10. UI test • Not leaking implementation details by writing tests

    with ActivityScenario & Espresso. • Can run on emulators/devices. • Can run in JVM thanks to Robolectric. • Robolectric does not support IdlingResource.
  11. Front-door first • What about code that are not tested

    via UI? Do we not write tests for it? • It’s called front-door first, not front-door only. • Write test for repositories, APIs in usual way.
  12. Don’t overuse mock • We use mockk. • Developers love

    to create mocks, you can mock almost everything! • Don't modify the SUT. val sut = spyk(Sut())
  13. Don’t overuse mock • Don't modify the SUT. every {

    sut.doAction() } returns Unit ... verify { sut.doAction() }
  14. Don’t overuse mock • Depends too much on third party

    library. • 😵 • Upgrading the framework was painful (mockk 1.9 to 1.10)
  15. Don’t overuse mock • Don’t mock Android classes: ◦ Widgets

    (View) ◦ Adapter ◦ Fragment / Activity ◦ ViewModel
  16. Blackbox Whitebox 💖 💬 Exposing implementation details Represents real use

    cases
  17. None