Ah, thanks for pointing that out Michal. Glad to see it's being tracked, and I'm looking forward to the fix.
I'd love to see it fixed in 1.2, but the work-around I described is sufficient for now. Mike On Sat, Apr 18, 2015 at 11:41 AM, 'Michal Bendowski' via adt-dev < [email protected]> wrote: > This is about running from Studio, not gradle. Please see > http://b.android.com/156256, it should be fixed in the 1.3 timeframe. > > Thanks, > > Michal > > On Sat, Apr 18, 2015 at 1:58 AM Xavier Ducrohet <[email protected]> wrote: > >> This seems broken. I've tried it on the latest 1.2 beta and it's not the >> case. running ./gradlew testDebug only runs compileDebugJava from the >> tested project, not the full assemble. >> >> Can you test with 1.2.0-beta2? >> >> On Fri, Apr 17, 2015 at 5:21 PM, Mike Grafton <[email protected]> >> wrote: >> >>> Hey all, >>> >>> Android Studio's unit test support is awesome, but it's extraordinarily >>> slow on my current project. This is because we are using multi-dex. From >>> what I can tell, multidex forces a full dexing of all your code - which >>> means incremental dexing is useless. >>> >>> For us this amounts to about a 50 second wait every time we want to run >>> a unit test. This is pretty much unworkable for TDD workflows :( >>> >>> We noticed that Studio invokes both assembleDebug and >>> assembleDebugUnitTest when running unit tests. The latter of these is quite >>> fast because it does not dex. The task I run from the command line - >>> testDebug - also does not dex. >>> >>> So, it seems to me that it's unnecessary for Studio to be calling the >>> heavyweight assembleDebug target, and that assembleDebugUnitTest should be >>> enough. For unit tests anyway. Is that correct? Can this be changed in >>> Studio (or the Android or Gradle plugins). >>> >>> Or (most likely) do I have no idea what I'm talking about? >>> >>> FWIW, we worked around this on our project by hacking our build.gradle >>> to replace 'assembleDebug' with an empty task - but only when a certain >>> system property is passed in as true. We set this system property to false >>> in our gradle properties (and use an extra gradle task in our Application >>> run config to turn it to false in that case). >>> >>> Thanks for any input, >>> >>> Mike >>> >>> -- >>> 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. >>> >> >> >> >> -- >> 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/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. > -- 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.
