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 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. »
This post is a continuation of my attempt to reproduce my recent DevFest talk in written form.»
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. »
When building our Android apps, we can often wind up with a decent amount of code in our
RecyclerView.Adapters that we want to test. In this article, I briefly suggest two ways of structuring our
RecyclerView-related classes so that we can accomplish this.
Loaders are awesome…they’re essentially the best practice implementation of asynchronous data loading in your Activities.
-Reto Meier, Developing Android Apps Udacity Course The following code should make you nervous:»