World-Class Testing Development Pipeline for Android

Pedro V. Gómez Sánchez - pedro@karumi.com - @pedro_g_s - github.com/pedrovgs

World-Class Testing Development Pipeline for AndroidPedro Vicente Gómez SánchezSenior Mobile Developer at Karumi

pedro@karumi.com@pedro_g_sgithub.com/pedrovgs

Alberto GrageraTechnical Director

Jorge BarrosoGoogle Developer Expert

Davide MendoliaSenior Full Stack Engineer

Sergio GutierrezSenior Mobile Engineer

Let’s talk about testing!

This talk starts with some common problems.

What do we have to test and how?

What if our code is not testable?

Just because our tests are passing doesn’t mean your code is working.

Any conclusions?

We are doing something wrong if we can’t trust our tests. We need a solution.

The Solution: Testable Code + Testing Pipeline

The Software Architecture used has to hide implementation details.

Dependency Inversion Principle is going to guide your Architecture.

DIP is the most important S.O.L.I.D. principle.

Architecture - Testable Code

Activity

Presenter

Use Case

Repository

Domain Model

Data Source

Data Source Implementation

Use Case

Architecture is not enough.

Testing Development Pipeline

Your Testing Development Pipeline should define what you are going to test and how.

What do I want to test?

Test my code implements the business requirements.

Test my API Client, HTTP requests/responses and JSON parsing, are working as expected.

Test the user is watching in the App UI the expected messages.

In other words…

Test our Business Logic independently of frameworks or libraries.

Test our integration with the API.

Test our application UI.

These three points define part of the Testing Development Pipeline.

These three points define what we want to test.

How are we going to test this?

Test my code implements the business requirements.

Think in the test scope and try to check the state of the software at the end of the test execution.

Use the Dependency Inversion Principle to be able to use test doubles to simulate different test

scenarios and adjust the test scope.

Business Logic Tests

Show me the code!

Check the state of the software at the end of

the test execution

Implementation Details are replaced using Test Doubles.

The SUT is the GameBoy, the GBZ80

and the GPU.

Infrastructure needed?

The usage of test doubles are the key to adjust the test scope.

The Application architecture will help use to hide

implementation details applying the dependency

inversion principle

Now we can test our business logic without depending on any framework

or library. Inside an isolated environment.

The Result

Test my API Client, HTTP requests/responses and JSON parsing, are working as expected.

Start a fake server we have under control checking the API client is working given some

preconfigured scenarios.

API Client tests

Show me the code!

Given some HTTP responses the final

authentication state is correct.

Given a Json file with the response, an http status code, and an

endpoint the parsing is correct.

Initializes a fake http server where we can configure responses.

Now we can check if our integration with the API Client is working as it

should.

The Result

Test the user is watching in the App UI the expected messages.

UI Tests

Replace some dependencies using test doubles from the testing application to be able to simulate different

scenarios and check the UI is showing the correct information.

Show me the code!

Code Injected from the test application.

Asserts from the UI point of view.

Asserts from the User Interface point of

Helper methods or different creational patterns to create initial scenarios.

Configure your dependency injection

library from your Application class.

Mocking Library

Helper Methods

Replace Application’s dependency container

with a custom configuration.

Now we can write UI tests easily.

The Result

The Testing Development Pipeline is complete now.

Now we know what to test and how.

Now we can trust our tests.

Tools and libraries?

Business Logic Tests

● JUnit.

● Mockito.

API Client Tests

● JUnit.

● Mockito.

● MockWebServer.

UI Tests● JUnit.

● Mockito.

● Robolectric.

● Espresso.

● Dagger.

References● World-Class Testing Development Pipeline for Android blog post series.

● Kata Contacts. GitHub Repository.

● Kata TODO API Client. GitHub Repository.

● Kata Super Heroes. GitHub Repository.

● Android GameBoy Emulator. GitHub Repository.

● Google Testing Blog. Testing state vs interaction.

Questions?

World-Class Testing Development Pipeline for Android

Engineering

Transcript of World-Class Testing Development Pipeline for Android

Android Testing, Why So Hard?!

Testing Android applications with Maveryx

Android Testing 2

Wp Pen Testing Android Apps

Android Automation Testing with Selendroid

Software Testing In a DevOps Pipeline - QA Systems...Software Testing In a DevOps Pipeline Within a DevOps pipeline Cantata provides automated continuous unit and integration testing.

Android Penetration Testing

Android Testing: An Overview

実践Android Developer Testing

Android Testing Approach - SiliconIndia · Elements of a Structured Testing Approach Android Testing Methodology Model Based Testing ... Nearly 20% of TAT reduction –Standard Process

World-Class Testing Development Pipeline for Android

Android Unit Testing With Robolectric

Android Building, Testing and reversing

Android testing patterns

Rapid Android Application Security Testing

Testing Android Security

Testing and Building Android

Mobile Testing mit Android

Android Hacking and Penetration Testing

Pipeline , Process and Testing Services