Approaching Outside-in TDD on Android (Pt. 3)

Software craftsman at @novoda, currently focused on Android. Spaniard living in London.

In the previous post, we wrote the acceptance test as a first step and started creating the most external classes of our implementation. In this post, we will finish implementing the system, and will summarize what we have learnt during the process.

To finish the BankAccount class, we need to implement its last public method, showStatement. Let's dive into the next iteration of the inner loop cycle.

As a rule of thumb, once a class is done, the next step is to run the acceptance test to check the progress and to know what is the next collaborator to implement.

If we executed the acceptance test at this point, we would see that the TransactionRepository throws an UnsupportedOperationException. As we stated before, throwing an exception in the methods that we have not implemented yet will guide us through the feature implementation and will point us to the next collaborator to implement. It is quite important, as doing so, we have greater control over the current feature progress. We just need to follow the exceptions until the feature is fully implemented.

Now that TransactionRepository is done, if we execute the acceptance test, StatementFormatter throws an UnsupportedOperationException. That means that it should be the next one to be implemented.

Note that we are not going to fulfil the statementLines method yet. Instead we mock it and throw an UnsupportedOperationException accordingly. We will jump there when needed.

Once again, we run the acceptance test to check the progress and now it guide us to the lines method in the Statement class (The one that we just mocked in the previous inner loop to implement the StatementFormatter). Let's get rid of the exception and jump into the next inner loop.

We are now done with the Statement class. Let's run the acceptance test again to find out that the next class that needs to be implemented is the show method of the ShowStatementActivity.

If we execute the acceptance test at this point, we can see that it passes. We can consider the feature DONE as it passes the given acceptance criteria in an automated fashion.

Conclusions

To wrap-up the series, we are going to summarize what we have learnt and make some comments about our implementation.

We would like to mention that we have used Espresso to assert the state of the views in Android, but you could use the testing framework that works best for you, i.e. Cucumber.

That being said, we have found that outside-in is an approach that requires good design skills and that we need to have a good idea of how the design of the system will look like beforehand. It usually means that we have built a similar feature or system in the past and therefore we have an overall idea of what we need and where we are led to.

PROS

CONS

These series have now come to an end with this third post.

We hope you enjoyed and learnt something.

About Novoda

We plan, design, and develop the world’s most desirable Android products. Our team’s expertise helps brands like Sony, Motorola, Tesco, Channel4, BBC, and News Corp build fully customized Android devices or simply make their mobile experiences the best on the market. Since 2008, our full in-house teams work from London, Liverpool, Berlin, Barcelona, and NYC.

Let’s get in contact