Philosophical Hacker

As a profession, we also tend to be abysmally ignorant of our own history. David West, Object Thinking Almost two years ago, I wrote a couple articles that attempted to answer the question, “Why is testing Android apps so hard?” In those posts, I suggested that the standard architecture of Android applications is what makes testing difficult. This explanation of the difficulty of testing android apps raises a deeper, more historical question: why did an architecture that makes testing difficult became the default way of building Android apps in the first place? »

Imagine for a moment that there’s an annoying fly buzzing around your guests at a BBQ you’re hosting. You and your guests swat at it a few times, but no one manages to nail the sucker. You run into the house to grab a fly swatter, but you find that even if you wait for the fly to settle down somewhere, you can’t quite smash it. Frustrated and desperate, you decide to evacuate the party (and the state), get your hands on a nuke, and nuke the fly along with your backyard and neighborhood. »

More than 1000 apps…they have espresso tests for the first time using the test recorder…espresso adoption has also grown since the introduction of [the espresso test recorder]. Android Developers Backstage, Episode 37 Espresso Test Recorder, 31:10 Record-playback tools are almost always a bad idea for any kind of automation, since they resist changeability and obstruct useful abstractions. They are only worth having as a tool to generate fragments of scripts which you can then edit as a proper programming language… »

As I pointed out throughout my series of posts on writing testable Android applications, the key to writing testable Android apps, is creating and exploiting seams. During these posts, I pointed out two types of seams that are available in any OO programming language and any programming environment. In this post, I want to highlight some Android-specific seams that we can leverage to make our applications more testable and flexible. »

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures… Fred Brooks, The Mythical Man-Month Grand structures – whether they are conceptual, programmatic, or physical – require strong foundations. This is true in two senses. »

The more that I learn about testing, the more suspicious of Robolectric I get. I’m honestly starting to think that many of the heros of unit testing (e.g., Kent Beck, Michael Feathers, Steve Freeman, and Nat Pryce) would be pretty suspicious of Robolectric. Here are my concerns: Robolectric is largely1 a set of mocks for a set of types we don’t own. Mocking types we don’t own is not recommended by the folks who invented mocks. »

When I go to work, I’m afraid of three things. I worry that the new feature I’m implementing won’t work as expected the code I’m tweaking will break functionality that used to work the application isn’t architected in a way that makes it easy for me to adapt it to ever-changing business requirements Automated testing is supposed to help alleviate all three of these fears, but when we’re first getting started with automated testing, it can be difficult to know where to start. »

Mocks are a pretty standard tool in our android developer tool belt. The extent to which we should use this tool for unit testing is a complicated and controversial issue.1 Within the Android community specifically, I think that a part of the controversy is due to confusion over the intended use of mocks. More specifically, some android developers seem intent on mocking types they don’t own and on verifying all interactions of a target class with a collaborator. »

This post is just another installment in a series of posts that are a written version of my Florida dev fest talk. Last time, we talked about object seams and how they make our apps more testable. This time, we’ll talk about how link seams help you write more testable apps and how build variants are used to create link seams. What are link seams? “[code] contains calls to code in other files. »

In my last post, a continuation of a written version of the talk I gave at Florida dev fest, I tried to give an answer to the question, “What makes apps testable?” The answer: seams. Seams make apps testable, and in this post, I want to talk about a particular kind of seam: object seams. The key insight behind object seams in this: The fundamental thing to recognize is that when we look at a call in an object-oriented program, it does not define which method will actually be executed. »