Profile

Cover photo
Michael Evans
Works at LivingSocial
Attended University of Maryland, College Park
Lives in Washington, DC
1,189 followers|1,113,623 views
AboutPostsPhotosYouTubeReviews

Stream

Michael Evans

Shared publicly  - 
 
 
+LivingSocial is our new community sponsor for DevFestDC - 2015 www.devfestdc.org on Sep 11/12 in +AOL 
View original post
2
Add a comment...

Michael Evans

Shared publicly  - 
 
Ever wanted to use Espresso, but didn't know how to get it integrated with your network calls? Well maybe you should read this.
http://www.michaelevans.org/blog/2015/08/03/using-espresso-for-easy-ui-testing/

#androiddev
4
1
Nick Kerr's profile photo
Add a comment...

Michael Evans

Shared publicly  - 
 
I'm going to be speaking at @DroidconNYC about Annotation Processors. Join me! http://droidcon.nyc/2015/dcnyc/40/ 

#androiddev  
8
1
Ted Malaska's profile photoTiffany Matthew's profile photo
 
Super cool
Add a comment...

Michael Evans

Shared publicly  - 
 
Matthias Käppler originally shared:
 
My verdict for unit testing on Android: it's 2015, and it's still somewhat broken.

Perhaps not as broken as it used to be, but still broken in some really fundamental ways.

We've been using Robolectric 1 for a very long time in the SoundCloud app and built up a substantial test suite (cloc counts about 73K lines of test code), but building something that mission critical on legacy software is of course a ticking time bomb.

After all the recent fuss about improvements in Android unit testing, I spent quite some time evaluating the different approaches to select the one that would offer us the greatest benefit with the least amount of friction (side note: it's 2015--why does unit testing require time to make it work? It should be as straight forward as drinking a cup of coffee.) I have to say I left disappointed; some things are broken by design, others are just broken. Brief summary:

Variation 1: Running unit tests on a connected device
The obvious benefit here is one of confidence: you are instrumenting your code against an actual system image, with the same VM that will actually run your code in production. It's the real deal. In the past, this approach wasn't exactly a great solution for numerous reasons (poor emulator performance, impossible to use mocking libraries, no JUnit 4 support to name the biggest ones.)
This has gotten better: we have a JUnit 4 runner now [0], we have DexMaker (a bytecode backend for Dalvik) [1], and we have Genymotion, but one of the major problems still exists: the platform JAR is full of final classes and methods, so you either have to write your tests to take that into account, or move your code as far away from the platform as possible; which is likely a good idea anyway [2], but induces the cost of introducing abstractions that might purely exist for testability.

Variation 2a: Running unit tests on the JVM (not using Robolectric)
With the arrival of "experimental unit testing support" (now not experimental anymore), we can now run tests from src/test/java using ordinary test runners. Since it's an ordinary Java unit test, you can use ordinary test setups and libraries, too. Rejoice! However, this approach still has several drawbacks.
Although a Gradle task has been introduced that strips the platform JAR of all finals and method bodies, as soon as your test subject is somehow entangled with the platform, like when using Intents or Bundles, your test will likely fail, since all these classes are stubbed out. Since Intent or Bundle are foundational platform types, they typically don't appear as collaborators in constructors, so you either have to come up with awkward indirections ("intent providers") or, again, move your code as far away from the platform as possible (again, see [2]) You will also likely end up wiring a lot of mocks in your tests, making your tests hard to read and understand (after all, that's one reason why Robolectric was initially created)
A final annoyance: why on Earth am I not able to see both unit tests and acceptance tests at the same time? Due to some idiosyncratic behavior in either AS or Gradle's Android plugin, only one Gradle source set containing tests can be active at once, as chosen by the "test artifact" setting in your build flavors. So unit tests are piggy backed on a system that it wasn't really built for, and it means that any refactorings you apply to one source set will not apply to the other source set, which is just asking for trouble. I hope this is only temporary and will get addressed with future versions of the AS (I assume it's a shortcoming of AS.)

Variation 2b: Running unit tests on the JVM (using Robolectric)
After we tried so hard to move away from Robolectric 1, we closed the circle by opting for... Robolectric 3. At SoundCloud we decided it was the most preferable solution of the three. It comes with all the benefits of running a normal JUnit test, but doesn't penalize you for writing tests for classes that use things like Bundles directly. Unfortunately (--or fortunately?), the higher you go up in the layers, the more difficult it is (still) to unit test something, which is probably a signal that even with a powerful tool like Robolectric, you should test code that is close to the UI sparingly (if at all), and focus on testing presentation /logic/, business rules, and anything beneath. For instance, Robolectric hasn't quite figured out timing yet, so things like animations steered by a presenter might fail. [3] Overall it's a huge step forward from the initial release though, and comes nicely modularized. By combining test rules and base classes for your tests, you can also keep much of the setup boiler plate out of your actual test cases, so that you don't couple yourself too much to any RL specifics.

[0] http://developer.android.com/reference/android/support/test/runner/AndroidJUnitRunner.html
[1] https://github.com/crittercism/dexmaker
[2] https://blog.8thlight.com/uncle-bob/2014/05/11/FrameworkBound.html
[3] https://github.com/robolectric/robolectric/issues/1879
2
Add a comment...

Michael Evans

Shared publicly  - 
 
So yesterday I learned about a new support annotation (@Keep), and was going to write about it - but I realized after talking to a few people, not everyone knew about the support annotations at all! So read about @Keep and some others here:

http://www.michaelevans.org/blog/2015/07/14/improving-your-code-with-android-support-annotations/

#androiddev  
10
Antoine Merle's profile photo
 
@WorkerThread and @UIThread are also very useful! 
Add a comment...
Have him in circles
1,189 people
Julio Campos's profile photo
Marvin Mitchell's profile photo
Jamal Whited's profile photo
brandon houtz's profile photo
Colin Edwards's profile photo
Agrim Prasad's profile photo
Ben Huffman's profile photo
cnewyork's profile photo
David Belliveau's profile photo

Michael Evans

Shared publicly  - 
 
Super small easter egg in the new YouTube Gaming app (hit the app version a few times)
6
Add a comment...

Michael Evans

Development Patterns  - 
 
Ever wanted to use Espresso, but didn't know how to get it integrated with your network calls? Well maybe you should read this.
http://www.michaelevans.org/blog/2015/08/03/using-espresso-for-easy-ui-testing/

#androiddev
12
7
Richard Burgess's profile photoVladimir Bjelakovic's profile photo
Add a comment...

Michael Evans

Discussion  - 
 
+Tor Norbye +Alex Ruiz 

I'm very interested in the newly committed lint-test bits. Is the recommendation for using this new API to just copy how the other lint tests are written? (E.g. https://android.googlesource.com/platform/tools/base/+/master/lint/libs/lint-tests/src/test/java/com/android/tools/lint/checks/LogDetectorTest.java)
Copyright (C) 2015 The Android Open Source Project; *; * Licensed under the Apache License, Version 2.0 (the "License");; * you may not use this file except in compliance with the License. * You may obtain a copy of the License at; *; * http://www.apache.org/licenses/LICENSE-2.0 ...
3
Add a comment...

Michael Evans

Shared publicly  - 
 
 
Indulge your need for speed—safely. This #MapsHack turns your neighborhood into a racetrack. goo.gl/tDquA8
85 comments on original post
6
1
Steve Rodrigue (LEKO)'s profile photo
Add a comment...

Michael Evans

Development Patterns  - 
 
So yesterday I learned about a new support annotation (@Keep), and was going to write about it - but I realized after talking to a few people, not everyone knew about the support annotations at all! So read about @Keep and some others here:

http://www.michaelevans.org/blog/2015/07/14/improving-your-code-with-android-support-annotations/

  #androiddev  
21
4
Gabor Orosz's profile photoAnkur Nigam's profile photoAnnyce Davis's profile photoPablo Antonio Fuente's profile photo
2 comments
 
+Christophe Beyls​ couldn't write about them all! So I picked some commonly used ones and the new one that inspired the article. 
Add a comment...

Michael Evans

Shared publicly  - 
 
 
One of the big complaints about Chrome currently is that it's a battery hog, especially on Mac where Safari seems to do better.

The team has been working on addressing this; here are some cases that have recently been improved on trunk:

http://crbug.com/460102

Before: Renderers for background tabs had the same priority as for foreground tabs.
Now: Renderers for background tabs get a lower priority, reducing idle wakeups on various perf test, in some cases by significant amounts (e.g. 50% on one test).

http://crbug.com/485371

Before: On a Google search results page, using Safari's user agent to get the same content that Safari would, Chrome incurs ~390 wakes over 30s and 0.3% CPU usage vs. Safari’s 120 wakes over 30s and 0.1% CPU usage.
Now: 66% reduction in both timer firings and CPU use. Chrome is now incurring ~120 wakes over 30s and 0.1% CPU use, on par with Safari.

http://crbug.com/489936

Before: On capitalone.com, Chromium incurs ~1010 wakeups over 30s vs. Safari's ~490 wakes.
Now: ~30% reduction in timer firings. Chrome is now incurring ~721 wakeups over 30s.

http://crbug.com/493350

Before: On amazon.com, Chromium incurs 768 wakups over 30s and consumes ~0.7% CPU vs. Safari's 312 wakes over 30s and ~0.1% CPU.
Now: ~59% reduction in timer firings and ~70% reduction in CPU use. Chrome is now incurring ~316 wakeups over 30s, and 0.2% CPU use, on par with Safari at 312 wakes, and 0.1% CPU use.

The Chrome team has no intention of sitting idly by (pun intended) when our users are suffering.  You should expect us to continually improve in this area.
83 comments on original post
3
Add a comment...
People
Have him in circles
1,189 people
Julio Campos's profile photo
Marvin Mitchell's profile photo
Jamal Whited's profile photo
brandon houtz's profile photo
Colin Edwards's profile photo
Agrim Prasad's profile photo
Ben Huffman's profile photo
cnewyork's profile photo
David Belliveau's profile photo
Work
Occupation
Software Engineer
Employment
  • LivingSocial
    Software Engineer, 2013 - present
  • The Washington Post
    Software Engineer, 2011 - 2013
  • Financial Industry Regulatory Authority
    2008 - 2011
Places
Map of the places this user has livedMap of the places this user has livedMap of the places this user has lived
Currently
Washington, DC
Previously
College Park, MD - Rockville, MD
Links
Other profiles
Contributor to
Story
Bragging rights
Winner of the Project Glass hackathon / Can cook minute rice in 58 seconds.
Education
  • University of Maryland, College Park
    Computer Science, 2006 - 2010
Basic Information
Gender
Male
Birthday
September 28
Apps with Google+ Sign-in
  • Swing Copters
  • Easter Egg Hunt
Most beautiful ballpark that I've ever been to. Make sure to grab a shake from Shake Shack, and some nachos from Hard Times, and you're set for a beautiful afternoon watching the Nats action.
Appeal: ExcellentFacilities: ExcellentService: Excellent
Public - 2 years ago
reviewed 2 years ago
1 review
Map
Map
Map