Testing with Fake Android SDK objects of final classes

330 views
Skip to first unread message

Vincent Scheib

unread,
May 31, 2015, 9:09:48 PM5/31/15
to Chromium-dev
I'm bringing up Bluetooth support on Android. Under test, I'd like to set a fake android.bluetooth.BluetoothAdapter, which would return a tree of related fake objects (BluetoothLeScanner, ScanResult, BluetoothDevice, BluetoothGatt, BluetoothGattService, BluetoothGattCharacteristic, ...)

BluetoothAdapter, BluetoothLeScanner, BluetoothGatt are a final classes. I'm new to Java, but so far my research shows this adds a hurdle to testing that can be overcome by:

+ Wrapping all calls to the AndroidSDK objects with an interface I define, passing through in the default implementation or returning fake results/objects in a test implementation. Due to the nested final classes, the wrappers will return wrappers (or alternatively flatten the object hierarchy a bit). The obvious downside is diluting the codebase with low value indirection.

+ Using a mocking tool such as PowerMock to create fake objects. (Doc on final classes) Code to create fakes is much simpler, but I don't believe we have any solution available yet that can fake final classes.

I have yet to find chromium code that fakes Android objects -- please point me to examples if you know them.

Know of another solution? I'd love to hear it.

Unless there's consensus that we should really consider adding e.g. PowerMock to chromium then I'll go down the wrapping route.

Elliott Sprehn

unread,
Jun 1, 2015, 4:13:57 AM6/1/15
to Vincent Scheib, Chromium-dev

I'd wrap in an api that flattens the hierarchy and provides very high level operations specific to how we're using the low level android api, only expose the bare minimum for what we need. That also insulates us from sdk rev changes.

Anthony Berent

unread,
Jun 1, 2015, 4:28:05 AM6/1/15
to esp...@chromium.org, Vincent Scheib, Chromium-dev
For unit testing have a look at Robolectric, which provides a host testing environment for Android, including "shadows" of many Android classes. Robolectric was added to the Chromium repository a few months ago, and is starting to be used for Android testing (see, for example, https://code.google.com/p/chromium/codesearch#chromium/src/base/android/junit/src/org/chromium/base/LogTest.java&q=Robolectric%20lang:%5Ejava$&sq=package:chromium&type=cs)

On Mon, 1 Jun 2015 at 09:13 Elliott Sprehn <esp...@chromium.org> wrote:

I'd wrap in an api that flattens the hierarchy and provides very high level operations specific to how we're using the low level android api, only expose the bare minimum for what we need. That also insulates us from sdk rev changes.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Reply all
Reply to author
Forward
0 new messages