Saturday, April 18, 2015

Espresso book?

I have been using Espresso for more than a year now, and I love it. I am considering writing a book / recording a video class / giving talks & workshops on the topic, but it is a substantial amount of work so I want to gauge interest before I start. If this material is valuable to you, please let me know by filling this form.

The outline

Introduction

  • What is instrumentation testing?
  • What is Espresso?
  • Basic anatomy of an Espresso test

ViewMatchers

  • How do matchers work?
  • Combining matchers (Hamcrest & Espresso)
  • Matching inside an AdapterView
    • onData
    • onChildView
    • inAdapterView
  • Using RecyclerViewActions with RecyclerView
  • Custom matchers

ViewActions

  • click(): What happens behind the scene?
  • Custom actions
    • getConstraints()
    • perform()

ViewAssertions

  • matches(ViewMatcher)
  • doesNotExist()
  • Custom assertions

Intents

  • Incoming: setActivityIntent
  • Outgoing: ActivityMonitor

App synchronization

  • The notion of idling
  • Custom IdlingResource

Repeatable tests

  • Avoid external dependencies (network, device configuration etc)
  • Dagger and Mockito

Cast studies

  • Combining various techniques in real-world scenarios

Your input

As a start, I submitted a talk proposal to Droidcon NYC. Please fav this tweet if you want to hear it:

However, the talk is only 40-minute long, highlighting maybe a quarter of this outline. It will take a lot more effort to flesh out the whole outline, so please let me know your interest by filling in this form: http://bit.ly/1H0X4up. Thank you!

Thursday, April 9, 2015

Dagger 2 + Espresso 2 + Mockito

I've been doing Android instrumentation testing with Dagger, Espresso and Mockito, and I love it. To commemorate the launch of Dagger 2 out of SNAPSHOT, I am sharing a demo repo with Dagger 2, Espresso 2 and Mockito:

https://github.com/chiuki/android-test-demo

Dagger Components

Dependency injection allows our app and test obtain different modules. This is very useful for creating repeatable test cases. The demo app displays today's date in the format yyyy-MM-dd. We would like to test that against a known date, instead of depend on the actual date when we run the test.

In Dagger 2, a Component provides modules for your whole app, and defines where to inject them.

public interface DemoComponent {
  void inject(MainActivity mainActivity);
}
@Singleton
@Component(modules = ClockModule.class)
public interface ApplicationComponent extends DemoComponent {
}
@Singleton
@Component(modules = MockClockModule.class)
public interface TestComponent extends DemoComponent {
  void inject(MainActivityTest mainActivityTest);
}

ApplicationComponent is used when the app is run normally, and TestComponent is used during tests. Both components injects into MainActivity.

How does the MainActivity know which component to use? It injects via the DemoApplication, which stores the component.

private DemoComponent component = null;

@Override public void onCreate() {
  super.onCreate();
  if (component == null) {
    component = DaggerDemoApplication_ApplicationComponent
        .builder()
        .clockModule(new ClockModule())
        .build();
  }
}

public void setComponent(DemoComponent component) {
  this.component = component;
}

public DemoComponent component() {
  return component;
}

We call setComponent() in test, which runs before onCreate(), so the TestComponent is used. When the app is run normally, component will be set to ApplicationComponent in onCreate().

Mockito

The app has a Clock class which returns the current time.

public DateTime getNow() {
  return new DateTime();
}

TestComponent contains MockClockModule, which provides Clock as mocked by Mockito. This way MainActivityTest can supply a pre-determined date during test.

Mockito.when(clock.getNow())
  .thenReturn(new DateTime(2008, 9, 23, 0, 0, 0));

Since we have singleton modules, the same mocked Clock is supplied to the app. With that, it will display the provided date instead of today's date:

onView(withId(R.id.date))
  .check(matches(withText("2008-09-23")));

More

There is a lot more in the repo, including testing activity launch with intent and unit testing with JUnit. Please check it out:

https://github.com/chiuki/android-test-demo

Also, I am toying with the idea of writing a book on Espresso. Please take a look at the outline and fill in this form if you think I should write it!

Further reading:

Wednesday, March 25, 2015

GHC proposals: Rejection likely

The Call for Participation for Grace Hopper Celebration just closed last week, and I saw a flurry of proposal submissions on Twitter. I am very excited to see so many people stepping up to speak, but I have some bad news:

Your proposal will probably be rejected
Your proposal will probably be rejected

GHC attracts a lot of proposals. A lot. Women from all walks of computing submit their talk ideas. In the past years I have heard a lot of excellent proposals being rejected. Bottom line, it is a very competitive process.

Don't waste your proposal

Now that you have written your proposal, you should submit it to other conferences. There are always conferences looking for speakers. Some resources:

Still not sure? Tweet me and I will recommend conferences to you.

Monday, March 23, 2015

Sketchnoting: An Engineer's Approach

Write/Speak/Code is the first conference I tried sketchnoting, and people loved it. I was really surprised because I still consider myself someone who cannot draw, but somehow I am good at sketchnoting. How come?

Constraint satisfaction problem

Naturally, I will explain my approach with a sketchnote:

When I took Alexis' sketchnotes class three years ago, I was really hung up on the idea that I needed to draw. The repertoire of shapes and objects that I can draw is really small, so I never actually tried sketchnoting after the class.

What changed? I flipped the problem around. I phrased it as a constraint satisfaction problem. I am using a small toolbox to express ideas I heard. And as an engineer, I am extremely good at that.

In the sketchnote above, I wanted to convey the idea that illustrations do not need to be realistic. At first I wanted to draw two trees, one realistic, one not. But alas, I cannot draw a realistic tree. Instead of giving up, I worked around by drawing a box with a dotted line to represent the realistic tree that I am unable to draw. Problem solved.

I am not kidding when I say my toolbox is small. You can see it in the sketchnote. The plain old notes vs sketchnotes part. That is literally my toolbox.

Use a pen

The other breakthrough came when I saw The Sketchnote Handbook by Mike Rohde in my local library:

The most important thing I picked up from the book is to use pen instead of pencil. This forces me to always make progress instead of erasing and re-drawing and second-guessing myself. It also makes me more forgiving of my mistakes, and come up with creative ways to fix them.

In the toolbox about bullet lists, I made two bullets with stars, because a single bullet doesn't make a list. And then I realized that I have nothing to more to say. What to do? The second star was already drawn. With ink.

I ended up writing "There is no second point" next to the second star. And you know what? It now emphasizes the fact that it doesn't take much to make sketchnotes.

A lot of serendipity came from using a pen and being forced to make things work.

Find your style

I really enjoyed the The Sketchnote Handbook because it includes examples from many sketchnoters. I pick and choose techniques that works for me:

  • Some sketchnotes are very free form, popping images left and right seemingly randomly. That terrifies me. But many examples use a grid style. I came up with my own layout algorithm: top to bottom, and if an item took too little horizontal space, put something next to it. This is very similar to traditional note taking, just using a bit more horizontal space. I can do that.
  • Some sketchnotes fill the whole page, and the pressure to do so paralyzes me. But many examples have whitespace between the items, and that is totally okay.
  • The book recommended using a vertical layout for panels, drawing the face of one panelist on each column. There is no way I can draw portraits. So I skipped that part. But it also showed a few simple ways to draw people. Now Starfish Man is a regular cast member in my sketchnotes.

Share

This is the most potent motivator: Twitter. You know how some people take a screenshot of a block of text to get around the 140 character limit? That looks stupid. But I can totally post a sketchnote to stuff more content into a tweet. And it looks awesome. So awesome that I get lots and lots of retweets, which gave me the confidence to do more sketchnotes, which gets more retweets.





Gotta love that positive feedback loop!

Sunday, March 22, 2015

Write/Speak/Code: Code

The third day of Write/Speak/Code is dedicated to contributing to open source.

Speaker buddies offsite

I have known my fellow writing panelist Corey Latislaw for a while, and we have always been speaking buddies, pushing and supporting each other. Rather than attending code day, we decided to have an offsite to catch up.

Yes, we played hooky for a leisurely brunch at Feast and a lovely walk on High Line. And we talked about our next steps as public speakers, brainstormed talk ideas, and plotted the steps to make it happen. This is the hallway track taken to the next level :)

The art of being awesome

We headed back to the conference just in time for Jen Myers's talk.

The awesome machine

Write/Speak/Code is a great combination of practical advice and dedicated time to write, to speak, and to contribute to open source. It is also a congregation of amazingly awesome women, pushing and supporting each other. Everybody is super charged with energy, ready to take their endeavors to the next level. Or as Buzz Lightyear puts it, to infinity and beyond!

This is a part of the Write/Speak/Code series. Read more: Intro, Write, Speak.

Write/Speak/Code: Speak

The second day of Write/Speak/Code is dedicated to speaking: writing a talk proposal, and giving a lightning talk.

Work in pairs

We started the day with a few exercise to brainstorm talk ideas and find a partner with similar interests. Each pair worked together throughout the day to write the talk proposal and prepare the lightning talk. Thisbuddy system is a brilliant idea, not only to bound off ideas during the day but also to hold each other accountable after the conference ended. I hope everyone will keep in touch with her partner and push each other to propose to conferences, help each other refine the talks, and cheer for each other as we all step on the stage!

Conference Organizer Panel

To help us write better proposals, Write/Speak/Code put together a panel of conference organizers, sharing their experience on the other side of the table.

After the panel, we split into small groups, and speaker mentors gave feedback to the talk proposals written earlier.

Speaking Effectively About Your Work

Next lecture is from Melissa Collom on how to create engaging presentations.

Lightning talks

Just like Write day ended with writing, Speak day ended speaking: give a lightning talk! Each talk was recorded, so everyone received feedback on the spot and can also go back to watch and review their talk.

This is a part of the Write/Speak/Code series. Read more: Intro, Write, Code.

Write/Speak/Code: Write

The first day of Write/Speak/Code is dedicated to establishing credibility, then sharing expertise through writing.

Impostor Syndrome

After the introduction from Write/Speak/Code founder Rebecca Miller-Webster, the first order of business was to address the impostor syndrome. Neha Batra gave us a 6-step formula to fight it:

Own your expertise

Next we went through a bunch of exercises to come up with our expertise based on our knowledge and experience.

With that, we crafted a bio and brainstormed ideas to write or speak about.

Writing panel

I really like how Write/Speak/Code alternates between hands-on activities and lectures/panel. Next up is the writing panel, and I got to share my experience alongside Pam Selle, Debra Williams-Cauley, Julie Steele, and Corey Latislaw.

Writing sprint

We concluded Write day by writing a blog post. I just stepped off the writing panel, and realized that I forget to share my blogging formulas, so I ended up writing a blog post on how I write conference reports. Oh so very meta!

This is a part of the Write/Speak/Code series. Read more: Intro, Speak, Code.