使用ProGuard，对测试策略有什么影响？
由于 Android 上的 Scala 存在问题，我最近需要在 Android 上引入 ProGuard。我需要 ProGuard 的收缩功能，该功能会删除假定未使用的类。我非常担心删除类对可测试性的影响。
目前，我编写了在主机上运行的单元测试和在 Android 平台上运行完全集成的应用程序的验收测试。
通常，我会对相对完整的单元测试覆盖率和参差不齐的验收测试覆盖率感到满意。然而，考虑到在我的代码中我大量使用 Guice 依赖注入，到目前为止，根据我的经验，ProGuard 以我难以预测的方式删除代码。因此，它很可能导致我引入错误。
这让我相信我需要编写实现完全覆盖的验收/平台测试，因为在任何时候，都可能缺少一个类。
其他人有这样的经历吗？如果是这样，您的测试策略是什么？或者随着经验的积累，您是否会更加确信 ProGuard 正在删除的类确实是不需要的？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
ProGuard 不会破坏您的应用程序，直到它尝试在已删除的类和/或混淆的成员上使用反射或 Class#forName。
根据我的经验（Android 上也有混淆的 Scala），使用简单的冒烟测试很容易发现 ProGuard 对 Android 应用程序造成的问题。您知道项目中包含哪些库。如果其中一些使用反射或 Class#forName - 对它们执行冒烟测试。然后从 ProGuard 配置中排除必要的类/成员。
另请记住，您可以使用 ActivityInstrumentationTestCase2 和模拟器自动测试混淆的项目。如果您计划在项目中使用 ProGuard，请始终对混淆的 APK 执行仪器测试。
总之——不要害怕。相对而言，与 ProGuard 相关的问题很容易发现。
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.
我们已经对我们的 ProGuard 应用程序进行单元测试和“全面”测试已有相当长一段时间了，而且我们没有遇到“真正的”问题。我们遇到的唯一问题是当我们在测试中使用一些主应用程序中未使用的库方法时；在这些情况下，ProGuard 将从库中删除代码，我们必须手动将特定方法添加到
proguard.cfg中。哦，我们还使用 Guice :)
We've been both unit testing and "fully" testing our ProGuard-ed application for quite a while now, and we've had no "real" problems. The only issues we run into is when we use some library methods in our tests that aren't used in the main application; in these cases ProGuard will remove the code from the libraries and we would have to manually add the specific methods to
proguard.cfg.Oh, and we also use Guice :)