Well a time ago I started to add support for unit testing in more automated way. The whole idea is based of course on robolectric but blessed with Spock. You can check http://robospock.org/ for sample configuration.
It's my night project and it'd be great if I have more data how to improve the library and gradle plugin. Hope this helps W dniu wtorek, 18 lutego 2014 16:37:53 UTC+1 użytkownik Matthew Fremont napisał: > > 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]> 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]. >>> 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.
