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

Unit Testing- What, Why and How?

38f77168b7c5802adc9cc3a5cfcf031b?s=47 Niharika Arora
September 05, 2020

Unit Testing- What, Why and How?

Slides covering few aspects of Unit Testing:
🔹 Why testing is important
🔹 What are the various testing types?
🔹 Tools and Frameworks for Unit Testing
🔹 Get familiar with testing annotations
🔹 How to write tests?
🔹 How to write testable code?

Session Link : https://www.youtube.com/watch?v=JC2s8iCoQm8&t=4897s&ab_channel=Recro

38f77168b7c5802adc9cc3a5cfcf031b?s=128

Niharika Arora

September 05, 2020
Tweet

Transcript

  1. Unit Testing: What, Why and How? Niharika Arora Senior Software

    Engineer, 1mg
  2. Agenda • Why Tests?

  3. Agenda • Why Tests? • Tools and Frameworks

  4. Agenda • Why Tests? • Tools and Frameworks • Demo

  5. Agenda • Why Tests? • Tools and Frameworks • Demo

    • Writing Testable Code
  6. None
  7. • “Mobile apps are frontend apps, the real logic is

    in the backend, so backend apps should be tested instead.”
  8. • “Mobile apps are frontend apps, the real logic is

    in the backend, so backend apps should be tested instead.” • “Mobile apps are difficult to unit test, because most of the logic is done in the UI. At most, you should only care about UI tests.”
  9. • “Mobile apps are frontend apps, the real logic is

    in the backend, so backend apps should be tested instead.” • “Mobile apps are difficult to unit test, because most of the logic is done in the UI. At most, you should only care about UI tests.” • “Mobile apps are “simple” or “tiny” compared to backend apps. Thus, effort should be put in the features instead of wasting time making tests.”
  10. Why test?

  11. None
  12. Why test? • No recurring cost of doing fixes when

    things break in production.
  13. Why test? • No recurring cost of doing fixes when

    things break in production. • Maintenance and Refactoring becomes easy.
  14. Why test? • No recurring cost of doing fixes when

    things break in production. • Maintenance and Refactoring becomes easy. • Validating your changes.
  15. Why test? • No recurring cost of doing fixes when

    things break in production. • Maintenance and Refactoring becomes easy. • Validating your changes. • Debugging
  16. Why test? • No recurring cost of doing fixes when

    things break in production. • Maintenance and Refactoring becomes easy. • Validating your changes. • Debugging • Simplify integration.
  17. Why test? • No recurring cost of doing fixes when

    things break in production. • Maintenance and Refactoring becomes easy. • Validating your changes. • Debugging • Simplify integration. • The list never ends.
  18. Testing Pyramid

  19. None
  20. UI Tests

  21. UI Tests • Interact with the UI of your app,

    they emulate the user behavior and assert UI results.
  22. UI Tests • Interact with the UI of your app,

    they emulate the user behavior and assert UI results. • Slowest and most expensive tests as they require a device/emulator to run.
  23. UI Tests • Interact with the UI of your app,

    they emulate the user behavior and assert UI results. • Slowest and most expensive tests as they require a device/emulator to run. • Tools : Espresso and UI Automator
  24. Integration Tests

  25. Integration Tests • When we need to check how our

    code interacts with other parts of the Android framework but without the complexity of the UI.
  26. Integration Tests • How your code interacts with other parts

    of the Android framework but without the complexity of the UI. • Don’t require a device/emulator to run
  27. Integration Tests • How your code interacts with other parts

    of the Android framework but without the complexity of the UI. • Don’t require a device/emulator to run • Tools: Roboelectric.
  28. Unit Test

  29. Unit Test “ A software testing method by which individual

    units of code, are tested to determine whether they are fit for use. The smallest testable part of an application (Classes and Methods).
  30. Unit Test • Fastest and least expensive tests as they

    don’t require a device/emulator to run.
  31. Unit Test • Fastest and least expensive tests as they

    don’t require a device/emulator to run. • Testing one logical unit/component guarantee that our component works properly for the set of inputs that we expect.
  32. Unit Test • Fastest and least expensive tests as they

    don’t require a device/emulator to run. • Testing one logical unit/component guarantee that our component works properly for the set of inputs that we expect. • Tools : JUnit and Mockito
  33. Good rule of Thumb

  34. Anatomy of a unit test

  35. Anatomy of a unit test ▪ Arrange all necessary preconditions

    and inputs.
  36. Anatomy of a unit test ▪ Arrange all necessary preconditions

    and inputs. ▪ Act on the object or method under test.
  37. Anatomy of a unit test ▪ Arrange all necessary preconditions

    and inputs. ▪ Act on the object or method under test. ▪ Assert that the expected results have occurred.
  38. None
  39. Android Unit Testing Tools & Frameworks

  40. Android Unit Testing Tools & Framework • JUnit

  41. JUnit

  42. JUnit • Testing a class/method that doesn't call Android APIs.

  43. JUnit • Testing a class/method that doesn't call Android APIs.

    • Assertion-based testing
  44. None
  45. JUnit statement assertions assertFalse(condition) assertEquals(expected, actual, tolerance) assertNull(object) assertNotNull(object) assertSame(expected,

    actual)
  46. JUnit Annotations @Test @Before @After @BeforeClass @AfterClass @Ignore

  47. JUnit Limitations

  48. JUnit Limitations • Your Object/class have external dependencies

  49. Android Unit Testing Tools & Framework • JUnit • Mockito

  50. Mockito “ A Java framework allowing the creation of test

    mock objects in automated unit tests .
  51. Mockito features ▪ Mocking

  52. @Mock private lateinit var loginModel: LoginModel

  53. Mockito features ▪ Mocking ▪ Stubbing

  54. `when`(UtilityClass.isNetworkConnected()).thenReturn(true)

  55. Mockito features ▪ Mocking ▪ Stubbing ▪ Argument matchers

  56. `when`(UtilityClass.isEmailValid(ArgumentMatchers.anyString())).thenReturn(true)

  57. Mockito features ▪ Mocking ▪ Stubbing ▪ Argument matchers ▪

    Verifying number of invocations
  58. Mockito features ▪ Mocking ▪ Stubbing ▪ Argument matchers ▪

    Verifying number of invocations ▪ Verifying order of invocations
  59. None
  60. Mockito limitations

  61. Mockito limitations ▪ Cannot mock final classes

  62. Mockito limitations ▪ Cannot mock final classes ▪ Cannot mock

    static methods
  63. Mockito limitations ▪ Cannot mock final classes ▪ Cannot mock

    static methods ▪ Cannot mock final methods
  64. Mockito limitations ▪ Cannot mock final classes ▪ Cannot mock

    static methods ▪ Cannot mock final methods ▪ Cannot mock equals(), hashCode()
  65. Android Unit Testing Tools & Framework • JUnit • Mockito

    • PowerMock
  66. PowerMock

  67. PowerMock • Framework that extends other mock libraries such as

    Mockito with more powerful capabilities.
  68. PowerMock • Framework that extends other mock libraries such as

    Mockito with more powerful capabilities. • Enable mocking of static methods, constructors, final classes and methods, private methods, removal of static initializers and more.
  69. Writing Testable Code Or how not to lose your mind

    coding
  70. Writing Tests can be hard!

  71. When done right, results in a clean, easy to maintain

    codebase
  72. Good Unit Test

  73. Good Unit Test • Easy to write

  74. Good Unit Test • Easy to write • Readable

  75. Good Unit Test • Easy to write • Readable •

    Reliable
  76. Good Unit Test • Easy to write • Readable •

    Reliable • Fast
  77. Good Unit Test • Easy to write • Readable •

    Reliable • Fast • Truly Unit
  78. None
  79. Testable Code

  80. Deterministic

  81. Deterministic

  82. None
  83. None
  84. Can you guess why this code is non deterministic?

  85. Side Effects

  86. Red Flags • Static properties and Fields

  87. Red Flags • Singletons

  88. Red Flags • Static Methods

  89. Rule of Thumb

  90. Rule of Thumb • Write deterministic code • Minimize side

    effects • In essence, write pure functions Can impurity really be removed? • As much as possible, extract it out and keep it contained
  91. “Writing a test is simple, but writing a code that

    can be tested is not so simple”
  92. References Github Link - https://github.com/niharika2810/UnitTesting-MVVM-Kotlin-Koin-Coroutines-Sa mple Medium link - https://thedroidlady.com/2019/07/10/unit-testing-in-mvvm-kotlin-databinding.ht

    ml
  93. Resources https://android.jlelse.eu/better-testing-with-mvvm-ae74d4d872bd https://blog.mindorks.com/mockito-cannot-mock-in-kotlin https://blog.mindorks.com/using-mockito-in-android-unit-testing-as- a-pro https://www.raywenderlich.com/195-android-unit-testing-with-mockit o https://medium.com/@mohitaunni/tdd-in-andoid-a-brief-story-part-1- 22166d211750

  94. Let’s connect • LinkedIn : https://www.linkedin.com/in/thedroidlady/ • Medium : https://medium.com/@nik.arora8059

    • Github : https://github.com/niharika2810 • Twitter : https://twitter.com/theDroidLady • Personal : https://thedroidlady.com/
  95. None