Testing

PSA: Dont Use Espresso Idling Resources like Google does

2016-06-07

Roman Nurik: …That’s actually one of the harder things with writing good sample code. People are going to be copying and pasting the heck out of it so you can’t take those shortcuts that you sometimes hopefully aren’t taking. Chet Haase: I always take the shortcuts. That’s one of the more interesting things that the developer relations group does in general…we will put together tests and sample code for the features that we work but we really don’t have the time to dive in deeply and do it in a real context.…

Making a TDD-based HackerNews client for Android

2015-07-17

I’m using TDD to write a HackerNews client for Android. This post (and the ones that will likely follow it) share a little bit about some of the techniques I used to follow a TDD-based work-flow for developing this application. It also discusses the architecture that arises when Android apps are built with testability in mind from the ground up. …

Why Having Global Static References to Application Contexts is Probably not the Best Idea

2015-07-14

In my last post, I went over 6 things I wish I knew before I wrote my first Android app. One of the things I listed in that post was this: Don’t have static references to Contexts The reason I warned against this is that static references to Contexts can cause memory leaks. An astute reader pointed out that a static reference to an application Context wouldn’t cause a memory leak since the application Context is around for the lifetime the app is running anyway. I then qualified my warning by saying: Note: Technically, you can hold a static reference to an application Context without causing a memory leak, but I wouldn’t recommend that you do that either. In this post, I want to say a little more about why think having and using a static reference to an application Context is less-than-ideal. I emphasize “less-than-ideal” in the previous sentence as a way of highlighting what I’m not saying: I’m not saying that a kitten dies every time you use a static reference to an application Context. Once again, @codestandards is hilarious and relevant here: Please, for the sake of the kittens. pic.twitter.com/xaj7pNDVfH — Code Standards (@codestandards) February 24, 2015 Instead, all I’m doing in this post is offering a few points that suggest that using static references to Contexts is probably not the cleanest way of coding Android apps. …

6 Things I wish I Knew before I Wrote my first Android App

2015-07-09

My first app was terrible. It was so terrible, in fact, that I removed it from the store and I don’t even bother listing it on my resume’ anymore. That app wouldn’t have been so terrible if I knew a few things about Android development before I wrote it. Here’s a list of things to keep in mind as you’re writing your first Android apps. These lessons are derived from actual mistakes that I made in the source code of my first app, mistakes that I’ll be showing below. Keeping these things in mind will help you write an app that you can be a little prouder of. Of course, if you’re doing your job right as a student of Android development, you’ll probably hate your app later regardless. As @codestandards says, If the code you wrote a year ago doesn't seem bad to you, you're probably not learning enough. — Code Standards (@codestandards) May 21, 2015 If you’re an experienced Java developer, items 1, 2, and 5 probably won’t be interesting to you. Items 3 and 4, on the other hand, might show you some cool stuff you can do with Android Studio that you might not have known about, even if you’ve never been guilty of making the mistakes I demo in those items. …

My Response to Hannes Dorfmann on "the Circular Dependency Problem"

2015-07-08

In my last post, I argued that there are two disadvantages to Activities and Presenters. The first disadvantage is that they are often bloated classes. The second disadvantage is that these classes often have a circular dependency between themselves and their Views. Yesterday, Hannes Dorfmann made a comment on my post that was so thoughtful and excellent that I think its worth dedicating an entire post to responding to it. …

MVPR: A Flexible, Testable Architecture for Android (Pt. 1)

2015-07-07

Thorough unit testing helps us improve the internal quality because, to be tested, a unit has to be structured to run outside the system in a test fixture. A unit test for an object needs to create the object, provide its dependencies, interact with it, and check that it behaved as expected. So, for a class to be easy to unit-test, the class must have explicit dependencies that can easily be substituted and clear responsibilities that can easily be invoked and verified. In software engineering terms, that means that the code must be loosely coupled and highly cohesive —in other words, well-designed. Steve Freeman and Nat Pryce, Growing Object Oriented Software Guided by Tests Lately, I’ve been working towards making Google’s IO app unit testable. A part of the reason I’m doing this is to test the claims that Freeman and Pryce make in the above quotation about unit testing. Although I’m still not even done with refactoring one Activity in Google’s IOSched app, I’m already finding some truth to what they’re saying. The Activity that I’ve been working on is the SessionDetailActivity. If you’ve been following me for a while, you know exactly what Activity I’m talking about, but if you’re tuning in the first time, here’s what the SessionDetailActivity UI looks like: As I mentioned in the post that introduced this series, there have been several challenges to making the SessionDetailActivity unit testable. Unit testing its dynamically constructed views was a challenge that I discussed in my last post in this series, but in that post, I noted that my strategy for testing dynamically constructed views wasn’t entirely clean because of a circular dependency between Views and Presenters. This circular dependency is a symptom of a larger problem with how we structure our Android applications: both Activities and Presenters violate the principle of single responsibility. They are often responsible for at least two things: binding data to a View and responding to user input. This is a part of the reason why the SessionDetailActivity, a class that’s supposed to serve as a model for Android development, is over 1000 lines long. I think there’s a better way to structure our applications. In the next few posts, I’ll propose a new architecture that has the following properties: It breaks up the multiple responsibilities typically handled by Presenters and Activities It breaks the circular dependency that traditionally exists between Views on the one hand and Activities or Presenters on the other hand. It enables us to use constructor dependency injection for all of our objects that present data to the user and respond to user input. It makes our ui-related business logic classes easier to unit test, impossible to construct without the dependencies necessary to fulfill their responsibilities, and (slightly) more amenable to the use of composition and polymorphism to extend and/or modify object behavior. In this post, I will try to give some reasons why we might consider a new architecture for Android development in the first place. …

Unit Testing Dynamically Constructed Views

2015-06-06

Some view hierarchies in Android are specified statically. The structure of these hierarchies does not change at run-time. Occasionally, we need to have dynamically constructed view hierarchies, hierarchies whose structure change at run-time. We might need to, for example, add or remove a view depending on some data we’ve fetched or in response to some input. The SessionDetailActivity in Google’s IOSched app has a dynamically constructed view hierarchy. The number of tags associated with a particular IO session determines how many tag views are added to the SessionDetailActivity’s view hierarchy. In this screenshot, the “Distribute,” “Android,” and “Games” tags are added to the view hierarchy based on the tags associated with the “Going global with Google Play” IO session. In this post, I’ll outline an approach that I used to write the code that is both unit testable and able to dynamically construct the SesisonDetailActivity’s view hierarchy. This post is a part of a series of parts in which I discuss how we can take steps towards making Google’s IOSched app unit testable. …

Towards A Unit Testable Fork of Google's IOSched App

2015-05-31

In my recent Against Android Unit Tests series, I discussed the difficulties of unit testing android applications and proposed a different way of building applications that would enhance their unit testability. My proposal in that series was really largely a rough sketch of what it would take to make parts of Google’s IOSched app unit testable. More recently, I’ve started to fill in the details of that proposal by forking the IOSched repo and refactoring it to make it unit testable. In the next few posts, I’ll be discussing some of the challenges that arose when attempting to make the SessionDetailActivity unit testable within the IOSched app. In this post, I want to provide a broad overview of the challenges I’ll be discussing. …

An Introduction to Unit Testing on Android

2015-05-29

Yesterday at IO Extended Orlando, I gave a talk on testing. What follows is a written version of the presentation I gave. Android 1.2 introduced unit testing support. Now, we can run junit tests on the jvm while we’re developing our apps. During my talk, we’ll discuss the following questions: Why should anyone care about this new feature? What the heck is unit testing anyways? Briefly, I’ll also mention some of the challenges of writing unit tests for Android. …

What I've Learned From Trying to Make An Android App Unit Testable

2015-05-22

For the past few posts, I’ve introduced and showed how we would apply The Square Way of building Android applications. The primary motivation for The Square Way was to increase the unit testability of our applications. As I stated in the introduction to this series, most tests in Android are slow, instrumentation tests and/or tests that rely on third-party frameworks like Roboletric. The Square Way was supposed to help us write fast unit tests that didn’t rely on any third-party frameworks. Now that we’ve discussed why unit testing in Android is so difficult and seen how The Square Way resolves those difficulties, we are finally in a position to assess The Square Way as a whole as a method of creating unit testable Android applications. That assessment is the subject of this article. My assessment consists of the following three claims: Removing all compile time dependencies on the Android SDK is not necessary for us write fast unit tests for Android. (Its also not really a practical thing to try to do anyway.) Provided that we redefine The Square Way so that it does not require us to remove compile-time dependencies on the Android SDK, the only problem that arises when trying to apply The Square Way is simply writing all of boilerplate code. Fortunately, much of this boilerplate can be written for us by Android Studio. Dependency Injection is really the main “active ingredient” that allows The Square Way enhance the unit testability of our applications. …