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 AndroidPedro Vicente Gómez SánchezSenior Mobile Developer at Karumi

[email protected]@pedro_g_sgithub.com/pedrovgs

mailto:[email protected]


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

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.


http://blog.karumi.com/world-class-testing-development-pipeline-for-android



https://github.com/Karumi/KataContactsJava

https://github.com/Karumi/KataTODOApiClientJava

https://github.com/Karumi/KataSuperHeroesAndroid

https://github.com/pedrovgs/AndroidGameBoyEmulator

http://googletesting.blogspot.com.es/2013/03/testing-on-toilet-testing-state-vs.html


Questions?


World-Class Testing Development Pipeline for Android

Engineering

Transcript of World-Class Testing Development Pipeline for Android