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.…

An Alternative Multiproject Setup for Android Studio

2014-10-03

Google’s Gradle Plugin user guide recommends a method for configuring your gradle files to build multiple projects. That method has some shortcomings. In this post, I will briefly explain Google’s recommended configuration, note its shortcomings, and recommend a different way to configure your gradle files to support multi-project setups in Android Studio. The Google Way This picture illustrates how Google suggests we handle multi-project setups: our main “app” module is supposed to depend on library modules that reside within the project directory.…