[MUSIC PLAYING]
JOSE ALCÉRRECA: Hello, everyone.
My name is Jose Alcérreca.
I'm an engineer on the Developer Relations team.
In this talk, I'm going to walk you
through five ways Compose has changed how we test UIs. So
let's start with a wish list.
Tests should be easy to write.
They should run quickly, and they should be reliable,
but this is not always the case.
Compose was designed with testability in mind,
so can we say this is true now?
Well, not completely, but it has improved the testing experience
enormously.
So let's look at five ways it did.
We'll start with testing in isolation.
What does this mean?
When you create a Compose test, you
can launch one of your activities,
like we've always done, or you can start an empty one
and set the content yourself.
That content is a composable context.
So it can be anything-- a whole app, it can be a single screen,
it can be part of a screen, or even the tiniest composable.
Because Compose is declarative, whenever you set content,
that composable is basically going to tell you
what it needs to render.
In this example, a list of items and a callback, which
is normally empty in tests.
It's as easy as creating a preview.
The next improvement is about synchronization.
This is how the test knows when to send the next action
or perform the next assertion.
In the real world, you need to use tools and frameworks
like Espresso, which have ways to figure out
if the app is busy or idle, and views don't have a way
to tell you if they're busy.
However, that's exactly what Compose does.
It exposes a much more straightforward signal
to the tests, making them much more reliable and faster.
So if you've ever written a Thread.sleep in your tests,
and I see some guilty faces here,
now it's probably the time to remove them.
Of course, you still need to handle
all the asynchronous operations that
might be happening across all the layers of your app,
so check out our documentation on that.
The way this works is with something
called automatic synchronization.
And normally, you don't have to think too much about it,
unless, of course, you want to pause
it, which brings us to number three, controlling time.
In Compose tests, you can pause time
or advance the clock as much as you need to
and do an assertion at that point in time.
The assertion happens immediately.
You don't even have to wait for the clock to be advanced.
The way you do this is pretty simple.
You set the autoAdvance property of the main clock to false,
then you call advanceTimeBy, passing
a number of milliseconds.
Or you can also go frame-by-frame.
But why would you want to control time in tests?
Well, this is very useful for any apps that
handle time one way or another, like a stopwatch,
but it's also great for testing animations.
For example, you can verify state
or take a screenshot at particular times
and make sure that you never have regressions.
Speaking of time, the next one is about
waiting for things to happen.
As mentioned before, you should never sleep in your tests,
and you can rely on automatic synchronization instead.
However, as tests grow in scope, it
gets harder to deal with all the asynchronous operations that
are going on.
And in end-to-end tests, it might not even be worth it.
Instead of that, we can tell the test
to wait until something happens.
So for those few end-to-end tests,
there is a Compose API called waitUntil that I really
like for this scenario.
It will pause your test until its body is true.
So you can look for a particular element
or do whatever you need to synchronize your tests,
without waiting for an arbitrary time.
The fifth one is about testing state restoration.
Managing state and restoring it after a configuration
change, like a rotation or some foldable gesture,
can get tricky.
So it's important to test it.
You can emulate our configuration change
by restarting the whole activity using the recreate method
in activityScenario, which is an API in Android X test.
But now with Compose, you have a new option
called StateRestorationTester, which is very easy to use.
You just set the content through the tester,
and then trigger a recreation.
The state will be saved and restored
as if a configuration change happened,
but much quicker and simpler.
Testing UIs has improved a lot with Compose,
so if you need another excuse to migrate or start with Compose,
testing is a great one.
These were just five features, but there are a lot more.
So check out the Compose testing documentation
for more details and resources.
Thank you.
[APPLAUSE]
[MUSIC PLAYING]