Hi Per.
I have Robolectric tests running fine with build variants using the
Robolectric Gradle test plugin. The test plugin exposes tasks to execute
flavor specific test (with non-release build types).
I just had to do two things to get it to work,
1. Register new test source folders -
android.sourceSets.androidTestX.setRoot('src/testX'), where X is your flavor
2. Insert a hack to the "testX" task exposed by the test plugin to avoid
running tests compiled for a previously run flavor in the current flavor -
This may be a bug in the plugin or just in my build scripts, but I
essentially had to add a testX.doFirst where I delete any test classes
belonging to other flavors from build/test-classes.
Cheers
On Friday, 13 June 2014 00:39:25 UTC+10, Per Christian Henden wrote:
>
> Yes, subclassing android-classes may be a relevant use-case for some.
> I just need to test my non-android-specific Java code in an efficient
> manner.
>
> If Robolectric works for you, i.e. you are not using build variants and
> don't need to run additional on-device androidTests, then yes, of course,
> you wouldn't need anything else.
>
> Come to think of it, if you manage to keep the relevant classes completely
> android-free, you could build and test that code in a separate
> Gradle-project and depend on the jar it produces. This is hard in my
> experience, as you often need Context and Log.
>
> kl. 16:17:37 UTC+2 torsdag 12. juni 2014 skrev Jürgen Cruz følgende:
>>
>> Yes, the android classes mocked by mockito should work, except for final
>> classes (Bundle) or final methods. But as you said, testing a class that
>> inherits from an Android class (Activity, Service, BroadcastReceiver) will
>> not work since you can't mock them and you aren't running on emulator. But
>> everything else should work. And yeah you can use a robolectric gradle
>> plugin and just make your tests not use robolectric at all and you won't
>> have to reinvent the wheel.
>>
>> Jürgen
>>
>>
>> On Thursday, June 12, 2014 7:54:21 AM UTC-5, Per Christian Henden wrote:
>>>
>>> Yes, you don't get the real Android classes with Mockito, you get mock
>>> implementations, which is a nice solution for unit tests.
>>> Basically you specify through Mockito how each Android class that your
>>> test code depends on should behave. Typically this means instrumenting the
>>> Android classes to return some static dummy values so that your test code
>>> can do its work. It's not a good fit if you are testing things related to
>>> the GUI or Activity lifecycle.
>>>
>>> Thanks for pointing out that the workarounds suggested for Android
>>> Studio/IDEA for Robolectric-gradle applies to this case too :)
>>>
>>> kl. 14:16:14 UTC+2 torsdag 12. juni 2014 skrev Jürgen Cruz følgende:
>>>>
>>>> As far as I know, even with mockito, you can't run android clases in
>>>> JVM. That is why robolectric had to make a runner that intercepts the
>>>> bytecode and a lot more magic things.
>>>>
>>>> But you are having the same problem as robolectric users. The best I
>>>> have been able to do was to manually modify the .iml files to include the
>>>> source and the libraries folder to include the dependencies
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
