Thanks for sharing, Andreas!

I tried your suggestion, but I ran into the same issue as before, even with
the latest robolectric plugin.
It's possible that my issue is specific for libraries. There is a
stackoverflow post documenting the issue, see
http://stackoverflow.com/questions/23116409/android-tdd-the-saga-continues-with-robolectric-gradle

Is this the same issue you experienced? If it is, I'd like to compare our
build scripts more closely :)




On Sat, Jun 14, 2014 at 9:43 AM, Andreas <[email protected]> wrote:

> 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 a topic in the
> Google Groups "adt-dev" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/adt-dev/02SEm7JLDTE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.

Reply via email to