Thanks guys, I see stuff is moving in the direction I hoped, I am sure we'll be happily testing soon enough. :)
Sent from my Nexus 4 On Feb 11, 2014 9:11 PM, "Xavier Ducrohet" <[email protected]> wrote: > > 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 a topic in the > Google Groups "adt-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/adt-dev/Jj5nJsqR964/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- 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.
