Exploiting Android-Specific Seams for Testing and Flexibility

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

TDD > The Principle of Single Responsibility

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

Why I Don't use Robolectric

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

What Should we Unit Test?

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

How we Misuse Mocks for Android Tests

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

Build Variants and Link Seams

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

Object Seams and MVP for Testability

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

Why we Should Probably Write More Tests for Our Android Apps

This past weekend, I had the privilege of speaking about writing testable Android apps at Florida DevFest. This post is a written version of one of the major points I made in my presentation. Let’s start off with two descriptions of attitudes towards testing. The first comes from Kaushik Goupal (he’s describing an attitude, not endorsing it): Testing seems to be like going to gym. Everyone feels like “yeah. »

3 Ways of 'Getting to Green'

A part of the TDD work flow is getting a failing test to pass as quickly as possible. This makes sense if we think about how TDD is supposed to help us take smaller steps when we’re writing programs. Beck goes over three ways of getting a test to pass quickly in the fist part of TDD By Example. The first method is to fake it. Just hard code whatever values you need to to get the tests to pass. »