Table-driven tests with Gomock
Table-driven tests are a common testing pattern for go tests. Since I recently started working with gomock, I wondered if there was a way to use table-driven tests with gomock mocks. It turns out that this is definitely possible, and that’s what this post is about. Before I show how to combine table-driven tests with gomock mocks, I briefly review how gomock and table-driven tests work and I try to show why you might want to combine table-driven tests with mocks in the first place.…
Integration Tests in Go
Although Go has support for testing built in to its toolchain, certain kinds of testing can be a bit tricky. For example, it may not be immediately obvious how you would go about writing and running integration tests in go. This post contains info on how to write and run integration tests for your go code. Clarifying Terms As I’ve said before, many terms in software are vague or ambiguous. So, before I get into how to write and run integration tests, let’s make sure we’re referring to the same thing when we use the word “integration” test.…
Getting started with Gomock
In my last post, I talked about why I started using gomock, a mocking library that facilitates testing in go. If you found what I said in that post at all compelling, you might have decided to give gomock a try and you might have noticed that the documentation isn’t as helpful as it could be. This post is meant to supplement the documentation. It’s a brief tutorial on how to get started with gomock. …
Should we use mocking libraries for go testing?
A few weeks ago, I started learning go. Since I’m a wannabe TDD-er, I took a look at some resources on testing go code. I stumbled upon Andrew Gerrand’s excellent Testing Techniques talk in which he says this: Go eschews a lot of things, including mocks and fakes. “Alright cool,” I thought to myself. I’m down to “do as the gophers do” and eschew mocks. Later on during his talk, Andrew Gerrand mentions gomock, a mocking library, and reluctantly says [mocking libraries like gomock] are fine, but I find that on balance the hand-written fakes tend be easier to reason about and clearer to see what's going on, but I'm not an enterprise go programmer so maybe people do need that so I don't know, but that's my advice. Of course, after hearing that, I felt a little confused and unsure whether I should refrain from using mocking libraries in go. To make matters worse, I took a look at gomock and was surprised to find that its written by two engineers at Google. At that point, it seemed that the question of whether we should use a mocking library while testing go code is a bit of a contentious question, even within Google. I found the seeming contentious nature of this question pretty unhelpful and confusing when I was trying to get a handle on how to write good go code. However, it led me to do some research on the pros and cons of mocking libraries vs hand-written mocks, and in this post, I present the conclusions I came to based on my research: The apparent contentiousness about whether to use use a mocking library if probably partially due to vague terminology. If we are clear about our terms, the argument against using mocking libraries is not very compelling. …
Making a TDD-based HackerNews client for Android
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
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
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"
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)
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. …
I'm taking a brief hiatus from blogging here...
…so that I can focus on ensuring that Droid Journal has a successful inaugural edition. I did, however, just post on Droid Journal’s blog.