How to Make Our Android Apps Unit Testable (Pt. 1)

2015-05-01

Unit testing Android apps is hard, and sometimes it can be impossible. For the past two posts, I’ve been explaining why android unit testing is so difficult. The main conclusion from the last post is that it is difficult/impossible to unit test our Android applications because of the way we are encouraged to structure them. Google seems to want us to put our business logic in app component classes (e.g., Activitys, Fragments, Services, etc.). This approach to writing Android applications is what I have been calling the “standard way.” In this post, I outline an alternative approach to structuring Android applications that will make it easier to unit test them. As I pointed out in the introduction to this series, the approach that I suggest is a generalization of the approach that Square uses to remove Fragments from their applications. Since this approach is inspired by the folks at Square, I will call it “the square way.” The heart of the square way way is this: remove all business logic from app component classes (e.g., Activitys, Fragments, Services) and place that logic into “business objects,” POJO objects whose dependencies are injected, android-specific implementations of android-agnostic interfaces. If we follow the square way of developing our apps, we will be in a better position to unit test them. In this post, I explain how the square way would have us refactor non-UI app components like the SessionCalendarService I’ve been discussing for the past few posts. …

Why Android Unit Testing Is So Hard (Pt. 2)

2015-04-24

Edit: In the post that concludes this series, I point out that making unit testable Android apps does not require us to remove compile-time dependencies on the Android SDK and that attempting to do so is impractical anyway. Ignore anything in this post that suggests otherwise. In my last post, I showed that even the (intelligent) engineers over at Google have written some Android code that is simply untestable. More specifically, I showed that there’s no way to unit test the SessionDetailActivity’s onStop() method. I also gave a specific diagnosis for the untestability of onStop(): we can’t complete the arrange- and assert-steps of a test against onStop() because there is no way to alter the pre-act-state, nor is there a way to access the post-act-state for a test of onStop(). I ended the last post by claiming that some properties of the Android SDK, along with the standard way we are encouraged to structure our android apps, encourage us to write code that is difficult/impossible to unit test and by promising that I’d elaborate more on that claim in this post. Before I do that, let me say again that showing that the difficulty of testing Android applications is caused by the standard structure of android apps is important for the overarching goal of this series of articles. This series is an attempt to argue that we should consider restructuring our applications so that they do not explicitly depend on the Android SDK and its an attempt to present a robust architecture that will enhance the testability of Android applications. You can read the introduction to this series here. With that said, I can move on to trying to demonstrate the central claim of this post. There’s a standard way of developing android applications. Sample code and open source code alike both place an app’s business logic within Android app component classes, namely, Activities, Services, and Fragments. Going forward, I’m going to refer to this practice as “the standard way.” Here’s the central claim of this post: As long as we follow the “standard way”, we’re going to write code that’s either difficult or impossible to unit test. In other words, the untestable code that I pointed out in my last article is not a fluke. The standard way prevents us from unit testing key pieces of our applications. …

Why Android Unit Testing is so Hard (Pt 1)

2015-04-17

Edit: In the post that concludes this series, I point out that making unit testable Android apps does not require us to remove compile-time dependencies on the Android SDK and that attempting to do so is impractical anyway. Ignore anything in this post that suggests otherwise. Unit testing your Android apps can be extremely difficult. As I suggested in the introduction to this series, it seems clear that there’s widespread agreement on this. The many folks who responded to my introductory post, moreover, seemed to reinforce my claim that Android unit testing is tough: So, Android unit testing is hard. That much is clear. Why Android unit testing is so difficult, however, is less clear. Its true that a part of the difficulty with Android unit testing has to do with the nonsense that you have to overcome to get Roboletric started so that you can run your tests at a decent speed, but I think that there’s a deeper reason why we are having a hard time testing our applications: the way that Google has written the Android SDK and the way that Google encourages us to structure our applications makes testing difficult and, in some cases, impossible. I realize that this is a bold claim, so I will spend the entire post trying to establish it. In the following post, I’ll try to say more about how the “standard” way of developing Android applications encourages us to write code that is difficult/impossible to write sensible unit tests against. These posts are a part of a series in which I’m exploring the viability of enhancing the testability of Android applications by restructuring them so that application code does not directly depend on the Android SDK. Showing why the standard architecture for Android development makes testing difficult will both motivate and inform my alternative proposal for structuring Android applications, a proposal that I will outline in the fourth post of the series. …

Is Mark Zuckerberg a Douche-bag?

2015-04-16

Facebook has been catching a lot of heat in Europe lately. A 61 page critical analysis of Facebook’s data use policy was recently produced by Katholieke Universiteit Leuven, Belgium’s designated privacy watchdog. The report claimed that Facebook’s Data Use Policy (DUP) was violating European privacy law, or, to put the claim more crudely (and less accurately), that Mark Zuckerberg is a douche-bag for creating Facebook. In this post, I present an imaginary (philosophical) dialog between Belgium and Mark Zuckerberg. Imaginary Zuckerberg will try to fend off the specific criticisms lodged by Belgium. I’m hoping the dialog will kick off a discussion on whether imaginary Zuckerberg’s defense was successful and what other responses Zuckerberg might have that could be philosophically compelling. In other words, I want this post to kick off a discussion in which we’ll try to settle the question of whether Zuckerberg is a douche-bag. …

Against Android Unit Tests

2015-04-11

Edit: Since I’ve written this, I’ve come to realize that making unit testable Android apps does not require us to remove compile-time dependencies on the Android SDK. I talk about this realization in the post that concludes this series. Even the best among us admit that they struggle with testing their Android apps. Jake Wharton has said explicitly that the Android platform has traditionally been very difficult to test.¹ In the inaugural episode of their (excellent) podcast, Don Felker and Kaushik Gopal have echoed similar sentiments.…

Don't call it "MVP"

2015-04-06

Lately there’s been a lot of discussion about an alternative architectural pattern for Android development. The acronym that’s being used to denote this alternative pattern is “MVP.” I think that “MVP” is an inaccurate and confusing designation for this pattern. In this post, I will say why I think “MVP” is a bad name for the pattern, and I’ll suggest a different name for referring to it. What is “MVP?” There are plenty of blog posts out there that describe the “MVP” pattern, so I’m not going to do that here.…

How to Keep your RxJava Subscribers from Leaking

2015-03-24

Edit: Shortly after writing this, I realized that the solution that I present here isn’t very good. I’m leaving it here just in case it can serve as a building block for better solutions. Sometimes you don’t have control over the lifecycle of your Subscribers. In these cases, to avoid leaking your Subscriber, you have to unsubscribe from your Observable when you’re notified that your Subscriber is about to be destroyed.…

Why Pirating is Probably Wrong (.java)

2015-02-22

Why Ayn Rand's Psychology is Probably Wrong (or trivial)

2015-01-24

**Edit: **Some have pointed out that I’ve misrepresented Ayn Rand’s position in this post. From what I can tell, they are right. Either way, I still think the argument presented here is interesting and accurate as long as we change the conclusion to “Psychological egoism is probably wrong (or trivial)” I’ve met a surprising number of people in my life who believe that no one is capable of altruism. These people believe that everyone always acts to further their own interests.…

Build Apps Smarter With Archiva and Gradle

2015-01-18

Dependency management in both Eclipse and Android Studio can be a serious pain. Now that we have gradle, there’s a better way to build android apps: we can configure our library projects to publish maven artifacts to a maven repository and we can configure our app projects to consume those artifacts. Once projects are setup to produce and consume maven artifacts, building an app with many dependencies becomes much more manageable.…