Incompatible with Roboelectric

[Plastix]

I have found that AndroidDevMetrics causes Roboelectric tests to hang indefinitely. The work-around I found was to disable AndroidDevMetrics during unit tests.

See discussion here: https://github.com/artem-zinnatullin/qualitymatters/issues/145

[williamwebb]

Hmm, so a Roboelectric unit test will be bringing in the debugCompile version AndroidDevMetrics, which is not optimal for unit test. Personally I don't think this is an issue with AndroidDevMetrics, as it should bring in the debugCompile version for debug builds...

I think the approach you are taking with artem-zinnatullin/qualitymatters#158 is the correct one, manually injecting the a no-op implementation. Though I would be wary to make to make sure its only for the roboeletric tests(glance at the commit looks like it might be for all dev builds).

@Plastix do you have a differing opinion on how AndroidDevMetrics should handle this? Or do you think there is a specific defect that needs to be addressed?

[Plastix]

@jug6ernaut You make a good point. I'm not sure how AndroidDevMetrics should best handle this (if at all). I'm content with manually injecting a no-op implementation. Note that the Application classes where this injection happens are only used in the custom RoboelectricGradle unit test runner. Thus any debug build will still install AndroidDevMetrics normally.

From what I can tell only @vanniktech and I have this issue which makes me think the problem is some system-dependent conflict (Possibly an OSX quirk).

[jlw8ke]

Thanks, @Plastix

This led me on the right path, and what you have works for non-activity robolectric tests.

For activity robolectric tests however, AndroidDevMetrics will still attempt to do start the activity lifecycle analysis using ActivityLifecycleAnalyzer and cause a runtime error. This is enabled by default, even if you do not initialize AndroidDevMetrics.

I feel lifecycle analysis should be disabled by default, and only be enabled when AndroidDevMetrics.initWith(...) is called. In the meantime, I got the library working with robolectric by injecting a no-op proxy for the library similar to your link, and disabling the lifecycle analyzer with ActivityLifecycleAnalyzer.setEnabled(false) for the unit and functional test application classes

[Plastix]

@jlw8ke Glad I could help. What exactly do you mean by Activity Robolectric Tests? Are you referring to Robolectric ActivityControllers?

[jlw8ke]

Yep. I had some tests using ActivityController that didn't fully disable AndroidDevMetrics until I disabled ActivityLifecycleAnalyzer

[Plastix]

@jlw8ke Thanks. I'll keep that in mind. I am having issues with Robolectric ActivityControllers being unable to instantiate my activity classes. I get a runtime error saying it can't call the constructor of the activity object.

[williamwebb]

Having a flag set in the init method isnt a bad idea, but i think we should go for a different option entirely.

We need to disable the code injection period for these situations. Will require adding some flags in your build.gradle, or possibly might be able to determine based on which runtime version is included(real vs noop).

I will look into this later today.

[LuigiPapino]

This seems to works for me

AndroidDevMetrics.Builder androidDevMetricsBuilder =
          new AndroidDevMetrics.Builder(this)
               .enableActivityMetrics(!isRoboUnitTest())
              .enableDagger2Metrics(true)
              .showNotification(true);
      AndroidDevMetrics.initWith(androidDevMetricsBuilder);

 public static boolean isRoboUnitTest() {
    return "robolectric".equals(Build.FINGERPRINT);
  }

[Plastix]

Cool fix @LuigiPapino! I ended up disabling AndroidDevMetrics in my tests entirely by writing a wrapper around it and injecting a no-op version in my tests.

[OleksandrKucherenko]

Full fix:

https://gist.github.com/OleksandrKucherenko/a9e9360c7e1e27ece796a25d1bdc5587

missed line:

        // important to call! resolves issue with android-dev-metrics library during unit tests execution
        MethodsTracingManager.getInstance().init(context);

details: https://plus.google.com/u/0/+OleksandrKucherenko/posts/5AM2z4EVwxk