It's definitively not finished. Adding optional instrumentation options would definitively be good.
Passing single test/method/classes is something we want to do for sure. I'd like to reuse the same command options that Gradle has (--tests). See here: http://www.gradle.org/docs/current/userguide/java_plugin.html#sec:java_test On Sun, Apr 27, 2014 at 1:50 AM, [email protected] <[email protected]> wrote: > That s great news. I had quite a bit of code into my branch against AOSP > but could not finalise it properly. I am taking a look at your PR and have > couple of comments. Latest JaCoCo is 0.7-SNAPSHOT which seems to work > better when it comes to instrumentation. I don't remember the specific of > it but it would be beneficial to easily change the JaCoCo version. The > agent obviously need to be mapped to the same version running on device. > > I would also argue that having a map of key/value for instrumentation > options is beneficial in may ways. Especially that is how one can pass > information between the build tool/runner and the InstrumentationRunner on > device. CoverageFile and others could be modified but also the likes of > running single test/methods/classes could be pushed to that by the IDE. > On 26 Apr 2014 03:39, "Xavier Ducrohet" <[email protected]> wrote: > >> Hi, >> >> I started looking at offering extension points for your need, and >> realized that the only way to be sure was to have an actual use case of the >> extension points. >> We also had a somewhat urgent need for this with an internal team moving >> to Gradle and nagging me about proper coverage support. >> >> In the end, this it wasn't actually a lot of work after the original >> investigation, I ended up implementing code coverage (with Jacoco). It's >> built-in right now though I want to move it out later so that anyone can >> plugin their own solution if they want to use something else (yes, this >> would require changes to the test runner). >> >> The Jacoco plugin/extension are currently separate (But automatically >> applied) but the rest isn't, though it shouldn't be too hard to do when we >> decide to add an API to open it up. >> >> The code is here: https://android-review.googlesource.com/#/c/91712 and >> this will be part of the plugin version 0.10. >> >> >> On Mon, Apr 7, 2014 at 4:18 AM, Carl-Gustaf Harroch >> <[email protected]>wrote: >> >>> Sure, I can push to AOSP. We generally use github for code review >>> internally and have not pushed to AOSP. >>> >>> The deviceAction is mainly used to grab the coverage file prior to the >>> uninstallation of the APK. The file by default is held within >>> /data/data/<package>/files/coverage.ec. Given the SimpleTestCallable >>> uninstalls the app, we need a way to grab data prior to the uninstallation. >>> Ideally I would have it somewhere generic on the task side. >>> >>> The JaCoCo plugin is fully functional and we tested it on a rather large >>> project with instrumentation and espresso tests. The current JaCoCo plugin >>> could be pushed into the AOSP code but I could see some reasoning on having >>> it separated. If you rather have one PR for the JaCoCo instrumentation, I >>> could do so. >>> >>> >>> PS: to get Android full support to JaCoCo there is a need to change the >>> default InstrumentationTestRunner.java if one wants to remove deprecated >>> EMMA coverage ( >>> http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.4.2_r1/android/test/InstrumentationTestRunner.java/#InstrumentationTestRunner.generateCoverageReport%28%29). >>> Currently JaCoCo wrap that call to get JaCoCo coverage without the need to >>> change the runner ( >>> https://github.com/jacoco/jacoco/blob/master/org.jacoco.agent.rt/src/com/vladium/emma/rt/RT.java). >>> Ideally one would change the runner but that is another task in its own >>> right. >>> >>> On Friday, 4 April 2014 19:09:47 UTC+1, Xavier Ducrohet wrote: >>> >>>> I would rather see this been done directly in AOSP than on github and >>>> then moved to AOSP so that we can keep all the discussion on the same >>>> place. >>>> >>>> I'm guessing the deviceaction is used by your jacoco plugin? >>>> >>>> We're going to work on code coverage very soon, so this is timely, but >>>> be aware that we're thinking about focusing first on jacoco support (emma >>>> seems to be mostly abandoned at this point). >>>> >>>> We may want to offer hooks for other third party solutions but we'll >>>> probably want jacoco to be built-in. What's your end goal with your current >>>> plugin? >>>> >>>> >>>> On Fri, Apr 4, 2014 at 8:52 AM, Carl-Gustaf Harroch >>>> <[email protected]>wrote: >>>> >>>>> Xavier, I have an initial Pull request available against latest idea33 >>>>> to provide instrumentaiton options to the plugin. I pushed it to Github to >>>>> give visibility and discussion: >>>>> https://github.com/novoda/android-tools-base/pull/2 >>>>> >>>>> It does touch on a couple of files and notions (especially the idea of >>>>> DeviceAction which could be explored further). >>>>> >>>>> The actual code coverage is done separately here and is still being >>>>> worked on: >>>>> https://github.com/novoda/gradle-android-jacoco-plugin >>>>> >>>>> Let me know your thoughts. Happy to push it back into aosp if it meets >>>>> criteria. >>>>> >>>>> >>>>> On Monday, 17 March 2014 22:24:42 UTC, Xavier Ducrohet wrote: >>>>> >>>>>> We haven't started work there. We would definitively accept >>>>>> contributions. thanks. >>>>>> >>>>>> >>>>>> On Mon, Mar 17, 2014 at 3:19 PM, Carl-Gustaf Harroch < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I managed to get JaCoCo running within Gradle (preDex, postCompile) >>>>>>> while running a manual "adb am instrument..." as Exec command. This >>>>>>> suits >>>>>>> my needs but was wondering what the current status is? I could provide a >>>>>>> patched version of DeviceProviderInstrumentTestTask that would add >>>>>>> instrumentation functionality as part of the testOptions similar to >>>>>>> testOptions { coverage: true }. This could be extended to take any >>>>>>> argument as defined >>>>>>> here<http://developer.android.com/reference/android/test/InstrumentationTestRunner.html>. >>>>>>> Is this a work in progress ATM? >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> Xavier Ducrohet >>>> Android SDK Tech Lead >>>> Google Inc. >>>> http://developer.android.com | http://tools.android.com >>>> >>>> Please do not send me questions directly. Thanks! >>>> >>> >>> On Friday, 4 April 2014 19:09:47 UTC+1, Xavier Ducrohet wrote: >>> >>>> I would rather see this been done directly in AOSP than on github and >>>> then moved to AOSP so that we can keep all the discussion on the same >>>> place. >>>> >>>> I'm guessing the deviceaction is used by your jacoco plugin? >>>> >>>> We're going to work on code coverage very soon, so this is timely, but >>>> be aware that we're thinking about focusing first on jacoco support (emma >>>> seems to be mostly abandoned at this point). >>>> >>>> We may want to offer hooks for other third party solutions but we'll >>>> probably want jacoco to be built-in. What's your end goal with your current >>>> plugin? >>>> >>>> >>>> On Fri, Apr 4, 2014 at 8:52 AM, Carl-Gustaf Harroch >>>> <[email protected]>wrote: >>>> >>>>> Xavier, I have an initial Pull request available against latest idea33 >>>>> to provide instrumentaiton options to the plugin. I pushed it to Github to >>>>> give visibility and discussion: >>>>> https://github.com/novoda/android-tools-base/pull/2 >>>>> >>>>> It does touch on a couple of files and notions (especially the idea of >>>>> DeviceAction which could be explored further). >>>>> >>>>> The actual code coverage is done separately here and is still being >>>>> worked on: >>>>> https://github.com/novoda/gradle-android-jacoco-plugin >>>>> >>>>> Let me know your thoughts. Happy to push it back into aosp if it meets >>>>> criteria. >>>>> >>>>> >>>>> On Monday, 17 March 2014 22:24:42 UTC, Xavier Ducrohet wrote: >>>>> >>>>>> We haven't started work there. We would definitively accept >>>>>> contributions. thanks. >>>>>> >>>>>> >>>>>> On Mon, Mar 17, 2014 at 3:19 PM, Carl-Gustaf Harroch < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I managed to get JaCoCo running within Gradle (preDex, postCompile) >>>>>>> while running a manual "adb am instrument..." as Exec command. This >>>>>>> suits >>>>>>> my needs but was wondering what the current status is? I could provide a >>>>>>> patched version of DeviceProviderInstrumentTestTask that would add >>>>>>> instrumentation functionality as part of the testOptions similar to >>>>>>> testOptions { coverage: true }. This could be extended to take any >>>>>>> argument as defined >>>>>>> here<http://developer.android.com/reference/android/test/InstrumentationTestRunner.html>. >>>>>>> Is this a work in progress ATM? >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> 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. >>> >> >> >> >> -- >> 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 a topic in the >> Google Groups "adt-dev" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/adt-dev/xr7hnrHKYmI/unsubscribe. >> To unsubscribe from this group and all its topics, 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. > -- 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.
