>>Tony Voellm: Next up, we have Valera, who's coming back up to join us.
Some fun facts about him.
He was born in Soviet Russia.
And he says, we don't test Android, Android tests you.
So with that, he is going to talk to us about Espresso.
>>Valera Zakharov: Thank you, Tony.
It's a pretty nice day out there, I guess.
Can we get the slides up?
Oh, click it.
Hey, that works.
Great.
So I think Ari -- again, I'm coming back to what Ari said, because it was such a great
keynote.
Are we going to have beer or are we going to have coffee?
I want to agree with him, and I want to say that we're going to have coffee.
So my name is Neil -- I mean, sorry, Valera.
And I guess if you missed the presentation earlier today, I work in Google on making
the lives of Android developers easier, at least when they're at work.
Outside of that, you know, that's not our area of expertise.
So -- and one of the recurring themes that we've seen all over GTAC this time is that
developers need to write the tests.
And I'm really -- I mean, we've been talking about this for years; right?
And I'm really happy to hear that I think everybody is on board now.
But in order for developers to write the tests, the benefits of testing have to outweigh the
costs.
And I think Eduardo's presentation was just a perfect lead-in there.
And, unfortunately, in the Android land, especially in the area of UI testing, this has not always
been the case.
So as I said earlier in the talk, we analyzed why this was happening, and we decided to
-- you know, that it needs to be solved and that we need a fresh start.
And then we identified these three important characteristics of what the tests should be
like if the developers are going to write them.
But before I get into that, I think there's kind of an important point to be made.
And that is that at Google, at least -- I don't know in your organizations -- the -- we
support, you know, a bunch of different API levels.
And I think Simon actually showed a great image yesterday from the Android Web site.
And you can see the majority of users are actually still on Gingerbread and still on
ICS.
And as the next 5 billion people come in, you know, to join us in the mobile revolution,
you know what?
There's actually a high likelihood that they will be running low-end Gingerbread devices.
So, I mean, are we going to just kind of like leave those people behind?
No, we can't do that.
And at Google, a lot of our apps actually run as far back as Froyo and Eclair.
There are still a significant amount of users there.
But, you know, let's get back to -- on track.
So, actually, the point I was trying to make there is that, yes, whatever solutions we
come up and with whatever tests our developers are going to write, they need to work across
all of these platforms.
So easy.
It sounds easy; right?
When we talk about easy, I think we talk about two things.
First of all, it's the easy of deployment.
When a deficits down and starts writing a test, they don't want to install complicated
tools.
You know, they don't want to learn new things.
They just want to write a test; right?
And we've seen a great example.
I think the Twitter talk yesterday was awesome.
Like, when you make it easy for developers, they're going to do it.
And so with Espresso, we wanted to maintain that.
And I think most of the Android developers out there, they're familiar with instrumentation.
And we wanted it to be the same exact setup.
So Espresso is just a thin layer, just 600 lines of code on top of instrumentation.
So it is actually easy to set up.
But the next part is the API.
And the API, you know, really needs to feel intuitive, and it needs to feel familiar to
the developers.
We don't want them to have a very large learning curve.
And when we started thinking about the API, since we were starting from scratch, and sometimes
it's really useful, we just thought what does the tester, in this case the developer who
is writing the test, what do they want to did?
And they want to do what the user does; right?
We're talking about UI, user interface.
And the user really just wants to do three things.
They want to find an element.
You know, they don't really know it's an Android view, but it's some kind of an UI element,
they want to doing is with it like click and type.
And then they want to -- maybe not all users, but manual testers, they want to check some
state.
And I think users actually implicitly check state.
You know, if something crashes, they're unhappy.
So what if our framework just did this and nothing else.
That would be pretty cool; right?
But just as important as what the API does is actually what it does not do.
We want to do the right thing and we want to prevent you from doing the wrong thing.
So what does a device user not do?
A device user has no idea about the internals of the application.
They don't care about the fact that there is some activity running right now or, you
know, views.
And, you know, in our experience getting these internal objects is kind of dangerous because
the state of the application is constantly changing and if you're holding onto this object
it may get stale.
In fact, it will get stale.
So we left out this API that some of the other frameworks include, and so far we have not
seen the use case actually where we need it.
And then of course the other thing is for the test authors, what do they not want to
do?
And the first thing is we kind of talked about flaky tests and how we solve that, and a lot
of the frameworks out there, almost all of them that I've seen, provide this nice method
called wait until some timeout.
And let's just do a little poll.
After I click on a button, you know, any button on Android and it transitions to the next
screen, what's the right time to wait?
Two seconds?
Do I hear ten?
Five?
Okay.
Five.
It goes to the highest bidder.
Five seconds the right answer.
You know what?
I don't think that's true.
I actually cannot make that choice myself.
I mean, I'm not the operating system and I have no idea what's happening on the UI thread
right now, so I'm not qualified to make it.
So why are we asking test authors to make that decision.
That's just unfair.
So we left that out of Espresso also.
And then the last thing is boilerplate; right?
There are actually solutions for guarding against these concurrency issues and test
flakiness, but they require a lot of boilerplate to write.
So you know what?
Let's remove that also.
So this is how our API looks like, and I mentioned it.
I showed a slide earlier today.
You want to find stuff.
And the way that we do this is our entry point to testing is on view, it's a static method
and you pass us a matcher for the view.
So you just specify exactly how you want to find the view.
And UIAutomator actually has kind of a similar pattern, you would have recognized it.
What we did also is that we decided not to write our own stuff and we reused the wonderful
Hamcrest matcher library.
Those guys are really awesome.
Hamcrest at first, it just looks like it's too good to be true, and then it actually
works really well.
So I have some simple matchers here with ID with text, but Hamcrest allows you to write
all sorts of crazy stuff.
So you can just find that one view that you are going to work with.
And then you can do stuff and you can check.
So that's it.
That's our API.
So test framework authors, that's what they have.
But we know that we're not going to get the API right on the first, you know, first try,
and we are going to leave out some things that people are going to want.
So we provide three main extensibility points.
First of all, as I already mentioned, the on view method takes a Hamcrest matcher.
So that's really easy.
You go and look at how to implement that.
It's not that much code.
And so we have already some precanned matchers for you.
There's a lot more than that, but as I said, if you really want to write your own, go ahead.
I mean, all power to you.
Same thing with view actions.
We provide you with a collection right now, and, you know, if you want to write your own,
once again, it's easy.
Just implement the view action interface.
Same thing for view assertion but in this case, actually, most of the assertions you
are going to do is kind of like view matchers.
You're just going to say, oh, is this view -- does it have this property right now in
this current state.
And so we provide you with this generic matches method where you pass a view assertion.
Or sometimes you actually want to assert that if view does not exist in the current view
hierarchy, so we give you that method.
Once again, you can write your own.
So that's it for our API.
Reliability.
I mean, that's the other theme that we hear all over GTAC this year; right?
And once again, Eduardo's talk.
It's better to not have tests than to have flaky tests.
It causes us a lot of pain and we've seen the merry Christmas slide; right?
So unfortunately there is this assumption out there that UI tests are flaky; right?
And that there's nothing that can be done about this.
So how does Espresso address this point here?
Well, first of all, let me take a step back and ask how most test authors solve this.
By the way, I did not make this up.
I took this from the awesome Google code base.
You know, or maybe you're smarter than that.
Maybe you wrote an awesome wait until method that loops and retries and maybe has an exponential
backoff.
Or maybe you even got as far as this and this is actually even getting close to the real
solution.
But imagine if you had to do this for every single test action.
I mean, talk about boilerplate.
So Espresso, you know, we had this idea that we can actually solve this for the framework
authors, and so we started out by synchronizing with a UI thread and all of the UI events
and the choreographer in the new APIs and all of the stuff you guys don't want to hear
about, and all of that is actually isolated in a level that neither the framework authors
nor the test authors will have to worry about.
But then we discovered, we started testing it on real applications like, for example,
Google Shopper, and we discovered, hey, real applications, they do things like talk to
the Internet and they write to disk, and the primary way of doing that is to background
your tasks and use async tasks.
So we went ahead and we added synchronization with a default async task thread poll.
So you get that for free.
And then we're like, we're done; right?
And then we discovered more apps within Google, and I won't mention any apps but they implement
crazy stuff.
Like they go out and just reimplement Android all in the sake of performance.
And that case, like we didn't know what to do.
So we added an interface where we allow you to actually register with Espresso a resource,
and then, you know, you can actually tell us when you're application or your resource
is going idle and Espresso will wait to run the next test operation.
I won't have time to get into the nitty-gritty details so here is a simple recipe.
And, you know, so for each test action, we wait until the application is idle, and then
we do an amazing thing.
We get on the UI thread.
Why do we do that?
Because while we are on the UI thread, just like I am on stage, nobody else can be on
the UI thread.
Well, maybe until Tony kicks me out.
And then we find the view using the measure you provided to us.
We run your action or your assertion or whatever you provided to us.
And then also a very important thing is as we saw earlier today, some actions like, for
instance, the click action result in multiple events being placed on the UI thread.
So we actually wait until those events get processed and only at that time we get off.
And then if there's any crash -- you know, it happens once in a while -- we don't want
to crash the UI thread, it's not a good experience, so we catch all of the exceptions and we propagate
these in a user-friendly format to the test author.
So with this approach, everything really runs reliably.
And we have teams that actually run substantial amount of UI tests right now and their tab
builds are not flaky at all.
I mean their continuous integration builds are not flaky at all.
But there's actually another bonus.
And we didn't actually set out to make our framework super fast but it turns out when
you remove all those sleeps and wait-untils from your test and you actually run the millisecond
that your app becomes idle, things move really fast.
And so perhaps you have seen the demos today that we have showed.
All of those UI tests that are just flashing on the screen, those were running Espresso.
And I mean, sometimes the tests run so fast that they just flash on the screen and we
don't see anything.
So speed is always nice; right?
And finally, this point.
This kind of understated.
And what do I mean by durability?
Durability is the antonym of fragile, you know, fragile tests.
And here we didn't have to invent anything.
Instrumentation already provides us a great way of dealing with this issue.
And as I said, most of our applications are in this really fast development cycle, like
Eduardo mentioned in his talk.
And it would be really, really painful if every time a string change happened, your
test also broke.
And ideally, we want that to not -- never happen, or if it happens maybe it will happen
at compile time.
So the nice thing about instrumentation tests is they are actually compiled in with your
application.
So there is this connection that you can maintain.
So you can actually refer to elements by resource IDs versus just content descriptions.
So originally I was going to do a demo, but, you know, obviously I'm running out of time
already, so there's no way that's going to happen.
And also, it's kind of boring to watch somebody else code.
It's fun to do it yourself.
But I did for Espresso.
And I also shared this on my Google+ public stream, so guys can check it out, and I hope
that you do.
So a lot of the Google teams out there are already using Espresso.
We have several more that are on-boarding, and perhaps you may be wondering in the stock
whether you can also enjoy some Espresso yourself.
So after this talk I will be out in the micro kitchen and I will be making Espresso for
everyone.
>>> They can't go to the micro kitchen.
They don't have badges.
>>Valera Zakharov: Bummer, bummer.
I don't know, then.
I'll figure out something else.
So since I'm running out of time, I'm going to stop that.
So seriously, we would really, really like to make Espresso available to people because
we really like using it ourselves.
And we're just working out through some technical details right now, and hopefully in the near
future it will be possible.
So with that -- And when we do, and even right now, before we do, I just want to say we're
really looking forward to your feedback.
Do you think we're on the right track?
Do you think we're completely off track?
It would be great to hear your thoughts feedback.
Unfortunately, I think we're not going to have time for questions, but I am going to
be around, and I will be happy to chat with you.
>>Tony Voellm: Great, thank you.
Thank you, Valera.
That was awesome.
That was a good movie, too.
Puss and Boots.
Very nice movie.
I would probably give this cat just about anything.