JONATHAN GERRISH: Hello, everyone.

Welcome to this morning session on test-driven development

for the Android platform.

My name is Jonathan Gerrish and I'm part of the Mobile Ninjas.

We're a small team within Google who

are passionate about software testing.

Can I get a quick show of hands in the audience?

How many of you are actually writing tests

as part of your normal software development practice?

That's fantastic.

OK.

So if you've written tests for Android before,

you've probably used some of our tools.

We developed the Android testing support library,

which includes the JUnit for test runner

and rules, the Espresso UI testing framework,

and we're also active contributors

to Roboelectric, the open source Android unit testing framework.

So everyone is telling you to write tests,

but why should you really do it?

It's true that tests take time to write.

They're adding code to your code base.

And perhaps you've been in this situation

before, where your manager or client has been telling you

that they're slowing you down.

But there's so many compelling reasons to write tests.

Tests give you rapid feedback on failures.

So failures that are spotted earlier on in the development

cycle are far easier to fix than ones that have gone live.

Secondly, tests give you a safety net.

With a good suite of tests, you're

free to refactor, clean up, and optimize

your code, safe in the knowledge that you're not going

to break existing behavior.

Tests are really the backbone of sustainable software

development.

You'll be able to maintain a stable velocity

throughout the lifetime of your project,

and you're going to avoid the boom-bust cycles of crunch

feature time and the aggregation of technical debt.

So in software testing, there exists the concept

of the testing pyramid.

And this is made up of a number of layers.

And each layer brings with it its own trade-offs that you're

going to have to weigh.

At the lowest layer is the small tests, or the unit tests.

And these need to be very fast and highly focused.

That's why we recommend you run these kind of tests, what

is known as local unit tests.

And these are going to run on your local desktop machine.

The trade-off you're making with these kind of tests

is infidelity because you're not running

on a realistic environment and you're probably substituting

in a bunch of mocks and fakes.

As we move up the pyramid, we're now

into the realms of integration testing and end-to-end testing.

And the key with these kind of tests is to bring in fidelity.

That's why we recommend that you run

these kinds of tests on a real device or an emulator.

These are the kinds of tests that

are going to tell you that your software actually works.

However, they are less focused, so a failure

in one of these kind of tests might take a little longer

to track down than it would in a unit test.

And one of the big trade-offs you're making

is in test execution speed.

Because you're assembling multiple components,

they all have to be built and then packaged,

shipped to a device where the tests are run,

and the results are collected back.

That's going to take extra time.

There's no single layer in this testing pyramid

that can suffice, so what you need to do

is to blend in tests at each different tier,

leveraging the strengths of one category

to weigh off the trade-offs in another.

There's no real hard and fast rule here,

but Google's own internal testing experts

recommend the 70-20-10 rule of thumb

as the ratio between small, medium, and large tests.

Let's take a look at our workflow.

So with test-driven development, the idea

is that you start by writing your tests,

then you implement the code to make those tests pass.

And then when your tests are green, you can submit.

Again, a quick show of hands.

Who out there has test-driven their code,

tried test-driven development in the past?

OK.

Cool.

We like test-driven development because it

makes you think about the design of your application up front.

It gives due consideration to APIs

and the structure of your code.

With test-driven development, you're

also going to be writing less code because you only

write the code necessary to satisfy your tests.

This will enable you to release early and often.

As you're constantly green, you'll

be able to deploy a working application at a moment's

notice.

If you're following the test pyramid,

the workflow is going to look something like this.

First of all, we have a larger outer iteration

that's concerned with feature development.

Here, it's driven by a UI test, and the mantra

with test-driven development is Red, Green, Refactor.

We start off with a failing test,

we implement the code to make that test pass,

and then we refactor.

Inside the larger iteration are a series

of smaller iterations and these are

concerned with the unit tests.

Here, you're building the units required

to make the feature pass.

And again, you use the same mantra here.

Red, Green, Refactor.

Red, Green, Refactor.

Let's take a look at an example application.

The feature we're going to implement today

is the Add Notes flow to a sample note-taking application.

If we take a look at our mock-ups,

we can see that we start on a notes list screen

full of some existing notes.

There's a floating action button down at the bottom.

And the user will click this, taking them

onto the new add notes screen.

Here, they can enter a title and a description for their note

before clicking Save.

The note will be persisted and then

they'll return back to their notes list screen,

where they can see their newly added note,

along with any other notes that previously existed.

Coming back to our workflow for a moment,

remember that we start with a failing UI test.

So let's take a look at how this test would look using Espresso,

the UI testing framework.

The first step is to click on the Add Note button.

Then we enter the title and description and click Save

before returning to the notes list screen.

And here, we're going to verify that the note that we just

added actually shows up.

Now remember, with test-driven development,

we'll not implemented code just yet.

All we have to do is implement enough

of the application to satisfy the specification of our tests.

So an empty activity, and just the resources that we need,

will suffice.

Once we have that, we can run our test

and we'll see it'll fail.

Now we have to implement this feature.

So applications are built up of many small units.

These are small, highly focused, specialized components

that do one thing and they do it well.

Collections of these small units are then

assembled together so that their collaborations will

satisfy our feature.

Let's take a moment to summarize the key characteristics that

make up a good unit test.

As well as the normal conditions,

you're wanting to test your failure conditions, invalid

inputs, and boundary conditions.

You're going to end up writing a lot of unit tests.

Unit tests must always give you the same result every time.

So avoid depending on things that might change--

For example, an external server or the current time of day--

because this is going to bring flakiness into your unit tests.

Unit tests should exercise one specific aspect of your code

at a time.

You're wanting to see that a failure in a unit test

will lead you, very quickly, to a natural bug in your code.

And when you write unit tests, avoid

making too many assumptions on the actual implementation

of your code.

You want your unit test to test behavior.

That way, you avoid rewriting your test

when your implementation is changing.

And one of the most important aspects of unit tests

is they've got to be fast, especially because you're

writing so many of them and, during TDD workflow, running

them rapidly.

It would be terrible if you were discouraged

from writing tests or refactoring your code because

of the pain in the execution time of those tests.

And finally, unit tests are an excellent source

of documentation and the way it's constantly

evolving with the code as it changes,

unlike static documents that will stagnate over time.

Let's try a unit test for our Add Notes activity.

This activity is going to take in user input

and then we're going to persist it

to local storage on the device.

OK.

So we're going to create the Add Note activity class,

and this will extend Activity, which is an Android framework

class.

It has a view which is going to be inflated with a layout.

The user will enter their data here.

And then we're going to persist that note into Android

SharedPreferences mechanism.

It's conceivable that, as our application evolves,

so did our requirement.

And perhaps our storage requirements

evolve to persist the notes onto cloud storage

and we have to build some kind of a synchronization mechanism

for local storage for the offline use case.

And in these cases, we see opportunities for abstraction.

We might, in this example, see that we

can extract a notes repository.

However, one of the key aspects of test-driven development

is that we only start by writing the simplest case first,

and then we iterate.

So we're going to resist the temptation to do this early.

Let's take a look at a sample of what an idealized unit

test would look like.

They're generally built up into three stages.

The first stage is you're setting

the conditions for the test, and this

includes preparing the environment,

setting up your dependencies with their required state,

and preparing any input data.

Next, we'll exercise the code under test, before finally,

making assertions on the results or the state.

I like to clearly separate each of these three

stages of the test and bring the pertinent aspects of each test

front and center to make for a really readable test.

Up until now with the Android platform,

you're writing your unit tests using

the mockable jarring conjunction with a mocking

library, such as Marketo.

And let's take a look at an example

of a test written with Marketo.

OK.

Wow.

That's a lot of code.

OK.

So because we have so many interactions with the Android

framework, we're going to need to provide

stubbing behavior for all of them in order just to make--

just to satisfy the execution paths of our test.

And furthermore, because Android uses a lot of static methods,

we're forced to introduce a second mocking

library, PowerMock, that will handle

this special case for us.