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]<javascript:> > > 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 >>> >>> >>> > -- 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.
