Creating the Room-based repository implementations has mostly been trivial, with some notable exceptions. In some cases, our queries were fairly dynamic, so we had to build the SQL statement at runtime and use @RawQuery in the DAO definition. In some other cases, the data we wanted to persist wasn’t trivial and required some kind of conversion, which was done using Cupboard’s converters; luckily, Room provides the exact same feature, by means of Type Converter s.

Finally, some Cupboard-based repositories were performing side effects on other tables (remember, the database schema is very simple, to the point of relations being implemented manually). We decided to keep the current behavior, and to simply allow for a Room-based repository to have another Room-based repository or DAO as a dependency. Although not ideal, we agreed to revisit this after the migration to Room was completed, and on the upside, it still allowed us to perform tests in isolation.

The final step is to run the existing tests that were revisited in Phase 1. Room supports SQLite’s ability of running a so-called “in-memory” database: intuitively this means that, instead of persisting the data into a file, Room will simply keep it in memory, therefore making it volatile. In doing so, we were able to test the Room-based repositories as well as the Cupboard-based ones by simply providing the respective one in the dependency graph.

Creating an in-memory database with Room.

The most interesting fact about this approach is that you don’t need to have the new database fully migrated to Room to test it. Instead, you can test a subset of tables at a time, which comes with the huge advantage of allowing us to make sure that our queries were correct, together with the Room-based implementation, without even having to run the app once.

You don’t need to have the new database fully migrated to Room to test it

Once again, we decided to scatter the PRs into different releases, so to make sure that our changes weren’t affecting the overall functionalities of the application. So far, so good: the few regressions we had were caught during the stabilization phase of our release process, thanks to the joint efforts between the QA team and the Android team. It was time to move to Phase 3.