On Tue, Feb 11, 2014 at 11:54 AM, Diego Costantini <
[email protected]> wrote:

> Hi xavier, thanks for the clarification and the look ahead :)
>
> I understand that if I want robolectric:
> 1 - I should absolutely not have it in instrumentTest with robotium or
> espresso (I expected that much)
> 2 - the android plugin will not provide any help, which may or may not be
> provided by some additional independent plugin instead. If this is what's
> coming (or not), I hope that Jake will reconsider discontinuing his
> deprecated plugin...
> Perhaps I will try to go back experimenting a bit more with Jake's plugin.
>
> About the dependency order, definitely something could be "less" wrong,
> but the problem must be somewhere.
> During my efforts in the last 3 weeks I found out (at least) the following
> 4 issues:
> 1 - I had conflicting dependencies, and some of them (ASM 4.1 vs. 3.1) hit
> me only at runtime if not in a particular order. These and other
> dependencies have been tamed through group/module exclusion in gradle.
>

The problem here is that ASM 3.x and 4.x are not compatible with each
other. If you somehow depend on both in your dependency graph you are kind
of stuck.
Was that a dependency from a plugin? I've seen this reported somewhere
else? The problem is that the Gradle plugins aren't yet sandboxed and so
they run with the same classpath and this triggers a conflict in that
particular case.


> 2 - I needed to move junit >3.7 at the top, because some other dependency
> has an older version. This is a reason good enough to allow dependency
> order for junit testrunner classpath. And if Android is the one with that
> old junit, well it is pretty hard to go without it :)
> 3 - move robolectric dependency before android, otherwise it will use real
> implementations rather than the shadows (or whatever we call them). Again,
> this is how it works, this starts to make me think there might be nothing
> so wrong about wanting dependency order (btw: didn't intellij have one? is
> it conflicting somehow within the android studio implementation?)
> 4 - add my output classpath at the end, so my test classes can be found.
>
>
All of these ordering are due to having the same library on the classpath.
as I said earlier, I think it would be fine to use the same sourcesets but
compile them differently with different dependencies. One to generate a
test apk, one to run on robolectric.


> In light of that, I can understand there might be other priorities for AS
> and gradle android plugin (and some of the issues might be solved by other
> plugins), but I believe these issues should be eventually addressed for a
> reasonable IDE.
>
>
We do really want to improve testing on Android. It's no simple task though
and there are things happening, but it's going to take a couple of months.


>
> On Thursday, February 6, 2014 4:46:16 PM UTC+1, Diego Costantini wrote:
>>
>> Hi,
>> I am struggling to have robolectric + robotium in a multiproject in AS (I
>> am completely new to it and IDEA so forgive me if I am missing some
>> history).
>> I think the biggest problem is that I put everything into instrumentTest,
>> and this way I have to compile all dependencies altogether (which makes
>> issues depend on each other and appear exponentially :) ).
>> As far as I understood, the module dependencies settings in AS is
>> currently under construction, because I keep finding workarounds from the
>> past to the problems I have that suggest to move the dependencies order
>> (for robolectric - example: move junit and robolectric on top, add output
>> folder at the end, ...) and change some of them to provided instead of
>> compile (for robotium - java.lang.IllegalAccessError: Class ref in
>> pre-verified class resolved to unexpected implementation).
>>
>> My question is: in 0.4.4 is there any way to set them?
>>
>> And more medium term: is there really work in progress to (1) eventually
>> restore the AS settings to manipulate module dependencies and (2) make unit
>> tests a first class citizen (perhaps by making java and android plugins
>> compatible)?
>>
>> Thanks for the huge work!
>>
>  --
> 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/groups/opt_out.
>



-- 
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

-- 
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/groups/opt_out.

Reply via email to