World-Class Testing Development Pipeline for Android

Pedro V. Gómez Sánchez - [email protected] - @pedro_g_s - github.com/pedrovgs
World-Class Testing Development Pipeline for Android Pedro Vicente Gómez Sánchez Senior Mobile Developer at Karumi [email protected] @pedro_g_s github.com/pedrovgs

Alberto Gragera Technical Director Jorge Barroso Google Developer Expert Davide Mendolia Senior Full Stack Engineer Sergio Gutierrez Senior 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 View Presenter Use Case Repository Repository Domain Model Data Source Data Source Data Source Implementation Data Source Implementation Use Case 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 view.

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

World-Class Testing Development Pipeline for Android

More Decks by Karumi

Other Decks in Technology

Featured

Transcript