I'm pretty sure gradle slow start up will be fixed soon. Although I do not have any relations with their dev team, I'm sure about this point because they've proved their high development speed several times for me, and, if you look at their source code, you'll see that they do have a lot of unit tests too. Thus it must be a problem for them as well (also I've seen somewhere Xavier's note that he understands why people avoid switching to gradle due to poor performance, and recommends to take a look at gradle again in few months).
Also making unit test plugins using API I pointed you to does not mean that running tests will require dexing and assembling. Gradle is very flexible and always does only those things that are required to execute a specified task. Even now your or JW's plugin does not perform any dexing to run unit tests. So, as for me, invoking gradle tasks from IDE to run tests should not be treated as a problem in a long term. On 7 March 2014 00:56, Terry Chen <[email protected]> wrote: > To echo Mike's sentiments, I've found that even when running a simple > JUnit test in Intellij, Intellij's invocation of Gradle's assembleDebug and > testClasses takes an additional 2-3 seconds in the best case, and 15-20 > seconds in the worse case (usually the first invocation only). > > I may be in the minority here, but I'm currently doing test-driven > development 40+ hours a week. In the course of implementing Android code, I > definitely go through bursts where I run a single test in Intellij up to > twice per minute, in quick succession. For such a workflow, that extra 2-20 > seconds per test run can be quite disruptive. > > I see two potential tool team solutions here: > 1. Make the gradle invocation as fast as Intellij's built-in make > (especially the first invocation). > 2. In the case of pure junit testing, within the same module, have the > android-gradle facet defer to Intellij for building. > > I understand that there are several advantages to *not* building within > Intellij, and funneling all building to Gradle. Having one build / clean > path, less complexity, and consistent/consolidated support across multiple > IDEs come to mind. But I hope the disadvantages of this can also be > recognized. > > In my experience doing Java and Android development, I'm become accustomed > to working around / dealing the problems a unified build path address. The > performance hit this comes with when executing tests will be difficult to > side-step. > > Roman, the solution you linked to, if I understand it correctly, looks to > be more an API that would make developing gradle plugins (i.e > gradle-android-test-plugin) easier. What we would like is performant, junit > support in the official Android Gradle plugin....and for our plugin to be > irrelevant altogether. > > Best, > Terry > > > > > On Thursday, March 6, 2014 2:12:42 PM UTC-8, Mike Grafton wrote: > >> Thanks for pointing this out Roman. I am just getting up to speed on what >> work is currently in progress on this front. >> >> If I'm understanding this correctly, this mechanism will still require >> the IDE's build/run to invoke the gradle tasks. But this is what I'd like >> to avoid. This puts a complex dependency between the moment I decide to >> execute a test and the moment the JVM actually starts running it. >> >> The key to effective TDD is to have nothing besides a lightning-fast & >> dependable toolchain between you and test execution. For those of us doing >> TDD this is the holy grail of the Android build system. An incremental >> compiler run fits this description, but the full gradle-based toolchain >> doesn't. Mainly I don't want to pay the start-up time for gradle to run. >> While that problem might be solvable, there is also the fact that the >> toolchain does a lot of other things as well (DEX, variant processing, etc) >> that will cause pain during the TDD workflow. Robolectric is big & slow >> enough already - adding another mandatory 2 or 3 seconds every test >> invocation would be very painful. And further, a "pure" JUnit test should >> run in a fraction of a second - there is absolutely no reason to put the >> gradle toolchain in front of it. >> >> This vision implies that when running this style of test, you would lose >> the application assembly power of the toolchain. That's OK by me. At this >> point I haven't quite wrapped my head around the use case for product >> flavors; even if I used them, I would be OK with only testing them in a >> certain type of slow test that requires the full toolchain. >> >> Not everybody using Robolectric needs this workflow enabled. But those of >> us doing TDD would be very well served to have the option of a pure JUnit >> experience in our IDE, with the ability to choose to run tests requiring >> the heavier tooling on-demand, but on a less frequent basis. >> >> Thanks! >> Mike >> >> >> >> On Thu, Mar 6, 2014 at 12:24 AM, Roman Mazur <[email protected]> wrote: >> >>> Real IDE support for unit tests in a separate folder could be done with >>> extra artifact types API provided by the Android plugin. >>> https://groups.google.com/forum/#!topic/adt-dev/zIOJigPI-0Y >>> >>> I had played with it making a new plugin for robolectric tests, but AS >>> does not support this API yet. >>> Thus I stopped my experiments, and currently waiting for news about AS >>> supporting the feature. >>> >>> Also my personal feeling is that tools developers won't go beyond >>> supporting the mentioned API and won't provide full tests support running >>> on host JVM (and I agree it's a rather reasonable choice). >>> However they are going to make things flexible enough for us to >>> implement this. This does not seem to be a high priority though :) >>> >>> >>> On Thursday, 6 March 2014 00:01:39 UTC+2, Terry Chen wrote: >>>> >>>> Hey folks, >>>> >>>> We just released a new version of Jake's >>>> gradle-android-test-plugin....adding >>>> better IDE support for running Robolectric tests: >>>> https://groups.google.com/d/topic/robolectric/xsOpEwtdTi4/discussion >>>> >>>> This is working pretty well for a TDD workflow, except however when we >>>> run a JUnit test (whether it uses Robolectric's test runner or not), we pay >>>> the penalty of invoking gradle to build, which takes several seconds even >>>> when nothing has changed. This doesn't seem too bad maybe, but when you are >>>> running single tests or test suites all day long, it adds up. It would be >>>> really nice if running these "plain old" JUnit within an IDE did not invoke >>>> any gradle tasks. >>>> >>>> Based on other discussions in this group[i.e. 1,2], it sounds like >>>> "plain old" JUnit support within the same module is planned for the Android >>>> gradle plugin some time in the future. So, presumably our plugin is a >>>> temporary workaround; in the future it seems (with just the android gradle >>>> plugin) we would be able to run Robolectric tests alongside Android tests >>>> in the same IDE module, with a different source set. >>>> >>>> Can someone validate this? If so, will it be possible to skip gradle >>>> when running JUnit from the IDE? Any idea of when this might happen? >>>> >>>> -Terry & Mike >>>> >>>> >>>> [1] https://groups.google.com/d/topic/adt-dev/q62wePcjK7o/discussion >>>> [2] https://groups.google.com/d/topic/adt-dev/Y8-ppkWell0/discussion >>>> >>>> >>>> >> -- Best regards, Roman Mazur Software engineer at Stanfy (http://stanfy.com.ua) Skype: roman.mazur.f LinkedIn: http://ua.linkedin.com/in/romanmazur Twitter: http://twitter.com/roman_mazur -- 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.
