Send the link below via email or IMCopy
Present to your audienceStart 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
Behaviour Driven Development in Android Studio
Transcript of Behaviour Driven Development in Android Studio
The Promising Start...
The Arduous Journey...
I want to teach Java developers how to code Android...
using the latest tools and frameworks...
and demonstrating best practices in Agile software development...
including Behaviour Driven Development
Android Studio has built in support for instrument tests
Android Studio 0.4.3...
they run relatively quickly on the Genymotion emulator
Google has created a new framework for UI testing called Espresso.
Behavioural Tests with Espresso
Behavioural tests, or UI tests, are called Instrument Tests in Android
Instrument tests run on a real or emulated android device
Espresso eases the pain of Android instrument tests by taking care of synchronisation and providing a fluent, readable interface
allow your test to interact with views
are what you're testing
All three of these are customisable. ViewMatchers and ViewAssertions use Hamcrest Matchers under the covers.
Some Existing Behaviour...
Given I have opened the App
When I enter my name
And click on OK
Then the main activity should open,
And show a welcome message that includes my name.
...And an Espresso Test To Match
It's not exactly Cucumber, but...
Robolectric is popular in the Android community for unit testing
Fest for Android adds expressive power to unit tests
...and you can install the Intel HAXM* to improve performance of the Android emulator
*Hardware Accelerated Execution Manager
Senior Developer Consultant
huh? can't find parent for StyleData
Writing feature tests first helps us focus on our user's journey
Refactoring keeps our code clean and maintainable
Writing unit tests before code improves the structure of our code
It all adds
up to fewer bugs
recognises only ONE folder
for test sources
We're already using that folder for our instrument tests.
Hmmm.... We'll have to add a separate module for our unit tests
Gradle in Android Studio is not configured to run unit tests
OK, we'll use Novoda's gradle-android-test-plugin
Urgh. We have to DOWNGRADE Gradle from 1.10 to 1.9
!!! JUnit version 3.8
or later expected
Good Grief! Android bundles in JUnit 3.7 and Robolectric needs 3.8+. We have to add JUnit 4.11 at the head of the classpath
Class not found: HelloAndroidTest
Heck! Let's remove the support classes and raise the minimum SDK to 14.
Not a great solution. We'll keep looking for a better one.
We have to update the gradle build script or the run configuration to compile the test classes first
Tell Google that professional developers need support for unit testing
Call your local MP
Thanks for coming!
Visit Android Bootcamp on Github for more on BDD in Android
Build interest in testing in your Android community
Contribute to the Gradle Android test plugin
Keep an eye on the brick wall at
The Android framework runs in its own virtual machine, called Dalvik
When you're developing, the classes available to you are actually stubs
This makes it hard to do JUnit testing on classes that use the Android framework, eg Activities
Robolectric replaces the Android classes with its own Shadow Classes to allow unit testing
Your tests use the Robolectric test runner
Robolectric supplies some static methods for driving Activities through the lifecycle
You can customise the Shadow Classes if you need to.
Using FEST for Readability
FEST Android augments Hamcrest matchers with a fluent interface tailored for Android
What if Robolectric bites the dust?
Robolectric's shadow classes are not perfect simulators of the Android classes
When things go wrong, stubbing methods from your class with Mockito can be a solution
Mockito is also great for isolating your unit tests to the class under test, by supplying mocks for collaborating classes.
Some recommend creating test subclasses of your real classes. I don't.