Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incompatible with Roboelectric #20

Open
Plastix opened this issue Apr 12, 2016 · 10 comments
Open

Incompatible with Roboelectric #20

Plastix opened this issue Apr 12, 2016 · 10 comments

Comments

@Plastix
Copy link

Plastix commented Apr 12, 2016

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: artem-zinnatullin/qualitymatters#145

@williamwebb
Copy link
Contributor

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
Copy link
Author

Plastix commented Apr 12, 2016

@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
Copy link

jlw8ke commented Apr 21, 2016

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
Copy link
Author

Plastix commented Apr 21, 2016

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

@jlw8ke
Copy link

jlw8ke commented Apr 25, 2016

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

@Plastix
Copy link
Author

Plastix commented Apr 26, 2016

@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
Copy link
Contributor

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
Copy link

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
Copy link
Author

Plastix commented Aug 31, 2016

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.

srsudar added a commit to srsudar/GithubHotness that referenced this issue Nov 2, 2016
The tests were hanging due to AndroidDevMetrics. Inscrutable bug. See
here for eventual fix
frogermcs/AndroidDevMetrics#20.

Tests are currently failing due to a bug in the Android support library.
See this bug for discussion:
https://code.google.com/p/android/issues/detail?id=222597
@OleksandrKucherenko
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants