We've talked before about how we wanted to work more in Human Rights and Citizenship. Our work on Relaynet (now Awala) already gave us a taste, and it's something we want to invest in.

So you can imagine our joy when we were asked by OONI (Open Observatory of Network Interference) to help them with their Probe Android app. The OONI Probe app allows users to check if their Internet access is blocking any websites or apps. It also measures the speed and performance of their network. Their findings can be submitted to an open dataset, where researchers can find evidence of internet censorship worldwide.

It's also an open-source app, something we've grown in experience in the past years.

The OONI Android team have been doing some great work with the app. It has more than 100K installs, a 4.2 rating and it's their biggest source of censorship data. But they've felt the app was lagging behind on Android best practices, and that they lacked the tools to tackle it.

💡 What are some of the consequences of technical debt?

• Increased effort to make changes;
• More bugs;
• Harder to onboard new developers.

⚠️ Learn about 10 Signs of Technical Debt in your Android app

APPROACH

The first step we did was an assessment of the application. We run it and look at the code. We check what is outdated, what could be simpler and what could have a better architecture. And we run the existing automated tests and calculate their code coverage.

Then we came up with our goal for this first engagement, build a comprehensive test suite for the project. Here was our plan:

• Setup the test infrastructure
  • Write a Continuous Integration step that runs tests on every project update, to catch regressions.
  • Configure dependency injection to help refactor parts of the code, and make it easier to mock components for tests.
  • Create factories to generate fake data we could use in tests
• Build a safety net
  • Write UI tests that cover the main functionalities of the application. UI tests are easier to write, even without a good architecture in place. They are slower, so you don't want them as the main bulk of a test suite. But they are a good safety net to have in place.
• Test individually
  • Write unit tests for each component. Sometimes refactors are necessary to be able to test a component in isolation. But those refactors should be conservative. Only when a project has a comprehensive test suite, then there's confidence for more broad code changes.

RESULTS

In terms of quantitive results, over 15 days of work, we wrote 43 UI tests and 201 Unit tests, reaching a code coverage of 73% (previously it was 10%). Qualitatively, now the Android team have more confidence to build new features and improve the app architecture.

In the wrap-up meeting, we discussed future steps to continue improving the quality of the project. Hopefully we'll join them in the future on it.

➡️ Are you also working with Android in your company? It may be worth taking a look at your practices. Get in touch with us for an assessment, send us an email for hello@bloco.io ⬅️