When you start developing Android apps your main target will always be delivering a working application. But when your application became bigger it also became harder to test. You will lose your confidence that the functionality you added didn\u2019t affect any other part.<\/p>\n\n\n\n

At this point you start to think if there is something that can help you be confident that any added new features doesn\u2019t break your app. The answer is Testing<\/strong>.<\/p>\n\n\n\n

Test code is just as important as production code. It is not a second-class citizen. It requires thought, design, and care. It must be kept as clean as production code.
<\/em>\u2013 Robert C. Martin, Clean Code<\/em><\/strong><\/p><\/blockquote>\n\n\n\n

<\/figure>\n\n\n\n

Testing is divided into 3 categories:<\/h4>\n\n\n\n

1. Unit tests:<\/strong><\/p>\n\n\n\n

• Small tests that validate your app\u2019s behavior by testing one class per time.<\/li>
• Testing of units of code.<\/li>
• Each unit test tests specific feature.<\/li>
• Requires JVM environment<\/li><\/ul>\n\n\n\n

  2. Integration tests:<\/strong><\/p>\n\n\n\n

  • Medium tests that validate interactions between levels of the stack within a module, or interactions between related modules.<\/li>
  • Testing of how pieces being put together<\/li>
  • Tests application behavior<\/li>
  • Often involves testing of UI<\/li>
  • Requires Android environment (emulator\/physical device)<\/li><\/ul>\n\n\n\n

    3. UI tests:<\/strong><\/p>\n\n\n\n

    • Large tests that validate user journeys spanning multiple modules of your app.<\/li>
    • Slower and are less isolated so are not run as often and can be more flaky than integration and unit tests.<\/li>
    • Requires Android environment (emulator\/physical device)<\/li><\/ul>\n\n\n\n

      We will be talking about Unit Tests<\/strong>, and how to make sure that your logic do what should be done.<\/p>\n\n\n\n

      You will find the unit tests at the test <\/strong>folder, Each unit test is a separate method annotated with @Test. This for example is asserting that 2+2 = 4. Assert used to indicate expected results. And fails test when expectation not met.<\/p>\n\n\n\n

      class ExampleUnitTest {
          @Test
          fun addition_isCorrect() {
              assertEquals(4, 2 + 2)
          }
      }<\/pre>\n\n\n\n
      Tests grouped in classes for organization convenience and that allows execution grouping, and setup\/teardown grouping.<\/p>\n\n\n\n
      There are times when we need to run specific operations before\/after each test, Thus we can use @Before and @After annotations.<\/p>\n\n\n\n
      @Before
      fun setUp() {
          \/\/ Test pre-processing (for ex. initialization)
      }<\/pre>\n\n\n\n
      @After
      fun tearDown() {
          \/\/ Test post-processing (for ex. reset values)
      }<\/pre>\n\n\n\n
      And If you need to run operations once per class before\/after all tests you have @BeforeClass, and @AfterClass annotations.<\/p>\n\n\n\n
      Tests preserve and enhance the flexibility, maintainability, and reusability of the production code. If you let the tests rot, then your code will rot too. Keep your tests clean.
      <\/em>\u2013 Robert C. Martin, Clean Code<\/em><\/strong><\/p><\/blockquote>\n\n\n\n
      \n