Red, green, refactor. That’s the TDD flow. That much was obvious to me. However, refactoring is a pretty broad term. There are many reasons you may want to refactor code and as a result of this, I didn’t really understand what exactly was supposed to happen during the refactor step of the TDD loop until I finished the first part of Kent Beck’s TDD by Example. Actually, in the first description of TDD, Beck uses a more helpful description of the “refactor step. »
Kent Beck introduces TDD by Example with a little story meant to show the business value of automated testing: Early one Friday, the boss came to Ward Cunningham to introduce him to Peter, a prospective customer for WyCash, the bond portfolio management system the company was selling. Peter said…“I’m starting a new bond fund, and my strategy requires that I handle bonds in different currencies.” The boss turned to Ward, “Well, can we do it? »
According to Eric Reis, MVPs allow us to test our business’ most important “hypotheses.” This is supposed to help us “fail faster,” but I’m finding that there are real differences in how much effort we have to put into our MVPs before we can validate our business hypotheses. In other words, some MVPs are more capital intensive than others. This is a big deal because you often can’t get favorable investment terms until you’ve shown that you’ve got product-market fit. »
If you’re going to be successful, Richard, you need to learn to be an asshole. Erlich Bachman, Silicon Valley For those of you who don’t know, I was recently accepted into Starter Studio, an Orlando-based incubator to work on University Android, a codeacademy-like program for learning Android development. Every Monday night, Starter Studio brings in successful founders to talk about things they’ve learned along the way to success. »
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:»
I’ve been working on a unit test recorder for Android. After struggling to find a way to implement the unit test recorder,1 I decided to take a look at how Google implements the espresso test recorder. This post presents what I found when I dug into the source code of the espresso test recorder. Collecting User Interaction Info Before I took a look at the source for the espresso recorder, I half expected to find some fancy bytecode manipulation of the sort we see for the proguard or jacoco transformers. »
Last week, I introduced Vice, a proof of concept regression test generation library. Vice generates regression tests simply by exercising the code we want to test. This is neat, but there’s already something else out there that does something like this, and ultimately, Vice as it stands doesn’t answer a fundamental question I have about regression tests: if we can record functional UI tests using the espresso test recorder or apple’s test recorder, why don’t we have a unit test recorder? »
Changes in a system can be made in two primary ways. I like to call them Edit and Pray and Cover and Modify…When you use Edit and Pray, you carefully plan the changes you are going to make, you make sure that you understand the code you are going to modify, and then you start to make the changes. When you’re done, you run the system to see if the change was enabled, and then you poke around further to make sure that you didn’t break anything…Cover and Modify is a different way of making changes. »
In my last post, I argued that we should stop putting our app logic in Activitys and Fragments because it makes both unit testing and functional testing our apps more difficult. In this post, I’ll try to suggest a method of safely removing app logic from our Activitys and Fragments, drawing on a central idea discussed in Michael Feathers’ Working Effectively with Legacy Code: characterization tests. In the first section, I briefly introduce the idea of characterization tests. »