In my last post, I showed how we can apply The Square Way to UI app component classes. More specifically I showed how The Square Way would have us rewrite the
SessionDetailActivity so that we could unit test its
onStop() method. At the end of my last post, I said that I’d be spending this and the next post doing an overall assessment of The Square Way.
I actually won’t be doing that this post. I’ll be postponing the overall assessment of The Square Way until the next few posts. Instead, what I want to do in this post is simply present a few unit-testability guides. These cheatsheets summarize much of what’s been covered in the past few posts and provide you with simplified steps to follow if you are interested in enhancing your application’s unit-testability via The Square Way.
The first guide helps you determine if a class is unit testable in general. It mostly summarizes Why Android Unit Testing Is So Hard (Pt. 1). The ideas expressed by this guide, moreover, form the basis for my argument that the standard way of building android applications makes it difficult/impossible to write unit tests for certain classes, an argument that I articulate in Why Android Unit Testing is So Hard (Pt. 2).
The second guide gives you the steps to follow if you’re interested in following The Square Way of structuring your applications to enhance its unit testability. This guide summarizes How to Make Our Android Appps Unit Testable part 1 and part 2. Disclaimer: Just because I’ve tried to present the The Square Way in a pretty infographic, doesn’t mean that I think that its the best way increase an app’s unit testability. There’s still a lot to say about the disadvantages of The Square Way. Again, I’ll talk about those disadvantages in my next post.
Against Android Unit Tests:
- Why Android Unit Testing is so Hard: part 1, part 2
- How to Make Our Android Apps Unit Testable: part 1, part 2
- Quick Summary
- Followup: Summary
- Followup: Unit Testing Dynamically Constructed Views
- Followup: Testing in Android Studio 1.2