I've been experimenting with the 0.8 version of the plugin and Android Studio 0.4.4, and I hit upon an interim solution that achieves a better integration with the IDE than the other work-arounds I've seen.
Because the Android plugin has its own concepts of a source set and the build lifecycle that are not really interoperable with the Java plugin and the gradle Test task, I created a separate submodule for the unit tests. I called this module "unitTest", and unit test code is all under unitTest/src/test/java. The build.gradle for this submodule applies the java plugin and makes use of the core Test task. It's a bit of a hack to resolve the dependencies between the unit test module and the app module, but I've been able to get it work enough to achieve the following: 1. Run unit tests that use Robolectric both from the shell and with the JUnit runner in the IDE (to support debug and a TDD workflow). 2. Android Studio will automatically recognizes the src/test subtree as test code. 3. Android Studio will resolve symbols from the app code and its declared dependencies while editing the test code and completion works. 4. No need to duplicate the declared dependencies of the app within the test module. Here is an example build.gradle: https://gist.github.com/mfremont/9073002 Does this seem reasonable? I think it highlights some desirable additions to the Android plugin API: 1. a better way to reference the compile SDK used by the app/library module as a dependency 2. a better way to reference the compiled app/library classes that provides proper support for flavors and build variants 3. a better way to reference the AndroidManifest.xml and resources tree Exposing these aspects of the app/library module with an official API gives the developer the flexibility to choose the test framework and tools without requiring explicitly support of any specific framework or runtime within the Android plugin. This might even make it easier to implement automated BDD-style testing of an Android app at the controller layer. Thoughts? Suggestions? Thanks, Matthew Fremont On Thursday, September 12, 2013 6:50:24 PM UTC-4, Xavier Ducrohet wrote: > > Hey Jake. > > Yes. I agree 100% we need to have good unit test support. > > How we get there is more complicated. Until we have a better solution, > i'll help supporting robolectric. For instance, I need to update the model > so that your plugin can have IDE support. > > I'm sad it's taking so long to make really good progress on the build > system (I'm hiring!), but do know that testing is high on my list of things > where I want to bring massive improvements to the current situation. > > Xav > > > On Wed, Sep 11, 2013 at 9:22 PM, Jake Wharton <[email protected]<javascript:> > > wrote: > >> In my personal projects and at my job unit testing is an essential aspect >> of our development. I know that many other developers from professional to >> hobbyist join me in this. >> >> On-device testing has been around since API 1. It's a bit sorely >> documented, requires the presence of a device, and is slow to run. The most >> common variant of this type of testing is instrumentation testing whereby >> you write an app to test your app. This black/white box hybrid is extremely >> prone to breakage due to changes in the app flow, view hierarchy, or >> resources of your app. It is no doubt the slowest of slow. Unit tests are >> actually supported by this test solution but they suffer most of the same >> problems as instrumentation but to a slightly lesser degree. >> >> Unit tests are fast to run, fast to develop (assuming you scope them >> properly), and are friendly to running on both CI and local machines for >> every change. They're fundamental downside is that they run on the JVM and >> therefore cannot pass through Android code. In practice unit tests >> shouldn't really be relying on Android's code anyways. They're around to >> test isolated, local behavior of your code. Mocks or Robolectric just >> provided help when you're forced to touch an Android type. >> >> Ant, the Eclipse ADT, and the new Gradle plugin have never supported unit >> tests officially. Users of Maven, sbt, and other Gradle solutions have been >> afforded unit tests since the build tools were built on existing Java >> infrastructure and have leaned on it heavily. Nobody argues these are a >> replacement for instrumentation tests. They are a complement for a >> proverbial one-two testing punch. >> >> Ideally the infrastructure for accomplishing this will mostly be a >> duplicate of that in place for instrumentation tests (e.g., build types and >> flavors/flavor group support) and hopefully a lot of that code can be >> shared. >> >> Please, Xav and team, bring us this blessing for the first time as a >> first-party solution! >> >> --- >> Jake Wharton >> http://about.me/jakewharton >> >> -- >> 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] <javascript:>. >> 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.
