Android Test Driven Development

This series will be about testing in Android.

So in this first introduction article, by the end, you’ll understand :

• What is Test Driven Development.
• why should you write test cases.
• Type of test cases.

What is Test Driven Development (TDD)

In this process, you write the tests for the thing you are adding before you write the code to implement it.

1. add method /class : only signature of method you want to test ,not implementation
2. Add a test: Anytime you start a new feature, fix or refactor, you write a test for it. This test will specify how this change or addition should behave. You only write the test at this step and just enough code to make it compile.
3. Run it and watch it fail: Here, you run the tests. If you did step one correctly, these tests should fail.
4. Write the code to make the test pass: This is when you write your feature, fix or refactor. It will follow the specifications you laid down in the tests.
5. Run the tests and see them pass: Now, you get to run the tests again! At this point, they should pass. If they don’t, go back to step three until all your tests are green!
6. Do any refactoring: Now that you have a test that makes sure your implementation matches the specifications, you can adjust and refactor the implementation that you have to ensure that it’s clean and structured the way you want without any worries that you’ll break what you just wrote.

We will cover all these steps when we write down our first test.

Why should write test cases when we can do testing manually.

You can do that by opening your app clicking around and seeing and verifying
that everything works and i mean if something doesn’t work then you usually detect that with clicking around.

what is the problem with this approach is that it only detects errors once so whenever you want to check for.so whenever you want to check for errors then you need to open your app and click around which takes a huge amount of time and so what happens if you extend your app and then something breaks in the code that was previously working.

that is the real problem of manual testing because you need to test the same functionality over and over again even if it was already working and that just costs us so much time.

Type of test cases .

Unit test:A unit test could be, for example that we have a function of that takes a list of integers and

fun calculateSum(List<Int> intList):Int{

}

it calculates the sum of that list of integers and then we just give that function a list of integers that we created and we calculate the sum out of that and then just make sure that the correct result comes out afterwards that would be a unit test .

This wouldn’t be dependent on any other component of our app it’s just dependent on the single function and these unit tests should make up about 70 percent of the test cases of our app.

Integration tests: Integration tests test how different components of our app work together so for example how a fragment interacts with a viewmodel

it’s very important that you don’t confuse integration tests with integrated tests because that is a big difference and both of these terms you will hear very often so integration tests are just as i mentioned they will test the interaction between different components in your app but integrated tests are tests that rely on android components and therefore must run on the emulator .

so if you take the example with the sum function again then this wouldn’t be an integrated test because calculating a sum doesn’t rely on any android components such as the context or an activity it just doesn’t need that so it can run on the jvm directly and doesn’t need an emulator to be run.

For example ,following function

fun isPackageNameValid() {
    // Context of the app under test.
  val appContext =  InstrumentationRegistry.getInstrumentation().targetContext
    assertEquals("com.example.tdd",
        appContext.packageName)
}
This Function needs to access our app’s resources and for that we need the context then this would be an integrated test.So integration tests should make up about 20 of your test cases

UI Tests or end to end tests:Test a combination of features working together. They test large portions of the app, simulate real usage closely, and therefore are usually slow. They have the highest fidelity and tell you that your application actually works as a whole. By and large, these tests will be instrumented tests (in the androidTest source set) Example: Starting up the entire app and testing a few features together. Like if you log in and then
are navigated to the main fragment.