Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

The Test Driven Developers Android Testing Toolbox

No description
by

Dave Shah

on 17 September 2015

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Test Driven Developers Android Testing Toolbox

The Test Driven Developers Android Testing Toolbox

The Obligatory Introduction
@daveshah

Over The Next Several Months...
ActivityInstrumentationTestCase2
ActivityInstrumentationTestCase2
These Guys & Gals
REALLY Care About ATDD
Programming is the easy part...
it's communication that's tricky!
ATDD : “Acceptance Test Driven Development”
TDD: “Test Driven Development”
We are
NOT
EXPERTS
Just a dude with a story...
TDD
You are not allowed to write any production code unless it is to make a failing unit test pass.
You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
ATDD
(I declare) expertise in no single language or methodology and (am) immediately suspicious of anyone who declares such expertise.

@docondev
@GaryGJohnson

@angelaharms

@leviw

@eraserhd

@audienceofnone

We Wanted That Ideal Case
With a kick ass product owner!
Cucumber Driven Tests!
And Ruby!

Cucumber-JVM
3 different home-grown solutions

Robotium

Robolectric
Calabash-Android
Mockito
Guice
android.test.*

And Since...
UiAutomator
Appium
Dagger

And everything above has evolved!

The “highest” you could go pre SDK Tools Rev 21, SDK Platform API 16
Access to Instrumentation() - Which is pretty low level & powerful
JUnit3 style testing
Allows for Mock Intents to be sent to the Activity under test - and the system “should” respond
Slow… (spins up a good chunk of the system for test)
With power comes great responsibility!

ActivityInstrumentationTestCase2
Wraps quite a bit of the ceremony in using plain ol’ ActivityInstrumentationTestCase2 (Support for dialogs, toasts, navigation between activities)
Good at keeping up with Android version releases (last releases were within a couple of weeks from the Android release)
Still “IN” ActivityInstrumentationTestCase2 so all the power is there if you need it
Still the little AITC2 annoyances (Screen lockage - ugh!)
Slow - spinning up from scratch on each test!

Robotium
Further Down The Pyramid...
What About Plain Ol' Java?
Integration Tests Are A Scam
- J.B. Rainsberger (@jbrains)
Isolating Your Code From The Framework
Contract Testing With
android.test.*
ActivityUnitTestCase **
AndroidTestCase
ApplicationTestCase
LoaderTestCase
ProviderTestCase2
ServiceTestCase
SingleLaunchActivityTestCase
SyncBaseInstrumentation

android.test.*
android.test.MoreAsserts.*
Fest-Android (by Square)
Dependency Injection

http://developer.android.com/training/articles/memory.html#DependencyInjection
Guice / RoboGuice / Dagger
Do it early
&
TEST RELEASE BUILD THOROUGHLY!
Fast!!!
Hey look, I can have JUnit4!
No device / emulator *Not the actual Android framework
Tend to look like ActivityUnitTestCase’s
Great community and very active project
"Framework" control

Robolectric.runUiThreadTasksIncludingDelayedTasks()
@Config for testing things locale specific
...
@TimConner65

@ncapuana

Given
we're after some expressive tests
When
we're test driving Android
Then
our quest continues...
Cucumber-JVM
+ Native Driver
Robogherk
Gametel + Brazenhead
Calabash-Android
Easy setup
Similar architecture to Frank (for iOS)...
Supports the Frankly Protocol
Ruby Based
Limited to your app sandbox (AITC2 limitation)
Canned "web-step" like steps
com.android.uiautomator.*
SDK Tools >= 21
SDK Platform >= API 16
Black-box testing
JUnit3 (UiAutomatorTestCase)
No IDE integration as of yet
Higher level API in comparison with AITC2

Appium
*Cucumber-JVM also works
with your Plain ol' Java
Calabash-Android???
Robotium
So... what should I use?
Are you a collaborator of 1?
Does your team embrace or run from learning new things? ... no REALLY.
Polyglots or monolinguals?
Tip o' the spear or corporatey corpse?
Some Things To Ask Yourself
Choose A Tool That
(*you think*)
Will Foster Collaboration & Communication
Whole team collaboratively discusses acceptance criteria, with examples, and then distills them into a set of concrete acceptance tests before development begins.
Ensures that we all have the same shared understanding of what it is we’re actually building.
Ensures we have a shared definition of Done.
Would an example help here?...
http://testobsessed.com/2008/12/acceptance-test-driven-development-atdd-an-overview/
-Elisabeth Hendrickson
@testobsessed
Full transcript