Why do we never have time to do it right, but always have time to do it over?

First, Solve the problem. Then, write the code.

How do we test the product to find problems that only show up when all the pieces are combined and in the right place?

This is part 3 and the last part of the ongoing series of articles where we keep adding new screens with more complexity to a TODO app.

Part 1 — How to use TDD effectively to write android integration tests

Part 2 — Developing a Todo app with android integration testing following TDD approach

We will start off by adding update TODO functionality and later support for the complete TODO feature.

As usual, we will not focus much on the data part, where will keep saving Todos in the memory using ArrayList, which means it will be erased when you restart the app. That should be fine for our use case as that’s the part we are not focusing on and you can always replace the repository implementation with a real database if you want to persist it.

To continue reading further, navigate to our blog website.