With ProGuard, what is the impact on testing strategy?

Question

I've needed to recently introduce ProGuard on Android because of issues with Scala on Android. I need ProGuard for its shrinking feature, which removes classes presumed to be unused. I'm very concerned about the impact of removing classes on testability.

As it stands, I write unit tests that run on the host and acceptance tests that run the fully integrated application on the Android platform.

Normally, I would be comfortable with relatively complete unit test coverage and spotty acceptance test coverage. However, given that in my code I use Guice dependency injection heavily, so far it's been my experience that ProGuard removes code in a manner that's difficult for me to predict. Because of this it's very likely to cause me to introduce bugs.

This leads me to believe that I need to write acceptance/platform tests that achieve full coverage because at any point, there may be a missing class.

Do others have this experience? If so, what has been your testing strategy? Or with experience, do you become more confident that the classes that ProGuard is removing are truly unneeded?

Answer 1

ProGuard will not break your application until it attempts to use reflection or Class#forName on removed classes and/or obfuscated members.

From my experience (with obfuscated Scala on Android too) it is really easy to spot problems caused by ProGuard to your Android application using the simple smoke tests. You know what libraries you include in your project. If some of them uses reflection or Class#forName - perform smoke test on them. Then exclude the necessary classes/members from the ProGuard configuration.

Remember also that you can automatize testing of your obfuscated project using the ActivityInstrumentationTestCase2 and emulator. If you plan to use ProGuard on your project, always perform instrumentation testing on obfuscated APK.

In conclusion - fear not. ProGuard-related problems are relativity easy to spot.