World-Class Testing Development Pipeline for Android & iOS

Pedro V. Gómez Sánchez - [email protected] - @pedro_g_s - github.com/pedrovgs
World-Class Testing Development Pipeline for Mobile 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

This talk starts with some common problems.

What do I have to test and how?

What if my code is not testable?

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

Any conclusion?

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

The Solution: Testable Code + Testing Pipeline

What do we need to write testable code?

The Software Architecture used has to hide implementation details.

Dependency Inversion Principle is going to guide your Architecture. Talking about testing, the DIP is the most important S.O.L.I.D. principle.

Architecture - Testable Code Activity - View Controller 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!

Android

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 us to hide implementation details applying the dependency inversion principle.

iOS

Check the state of the software at the end of the test execution

Implementation Details are replaced using Test Doubles. But in the case of iOS is just for simplicity. The SUT is the GameBoy, the GBZ80 and the GPU.

Handmade test doubles :_( The Application architecture will help us 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 listening at some endpoints or use Objective-C swizzling, to test the API client is working given some preconfigured scenarios. API Client tests

Show me the code!

Android

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.

iOS

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.

Use swizzling to perform the HTTP stubbing.

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!

Android

Code Injected from the test application.

Asserts from the User Interface point of view.

Helper methods 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.

iOS

Code Injected from the test application.

Asserts from the User Interface point of view.

Base class to replace the root view controller.

Helper methods to create initial scenarios.

Handmade Test Doubles

Now we can write UI tests without a real server. The Result

The Testing Development Pipeline is complete now. Now we know what to test and how.

Now I can trust my tests.

Tools and libraries?

Business Logic Tests • JUnit. • Mockito. • XCTest. • Your hands.

API Client Tests • JUnit. • Mockito. • MockWebServer. • XCTest. • Your hands. • Nocilla.

UI Tests • JUnit. • Mockito. • Robolectric. • Espresso. • Dagger. • XCTest. • Your hands. • KIF • Creational patterns.

References • World-Class Testing Development Pipeline for Android blog post series. • Kata Contacts. GitHub Repository Android. - GitHub Repository iOS • Kata TODO API Client. GitHub Repository Android - GitHub Repository iOS. • Kata Super Heroes. GitHub Repository Android - GitHub Repository iOS • Android GameBoy Emulator. GitHub Repository. • Google Testing Blog. Testing state vs interaction.

Questions?

World-Class Testing Development Pipeline for An...

World-Class Testing Development Pipeline for Android & iOS

More Decks by Karumi

Other Decks in Technology

Featured

Transcript