I need multiple test contexts. I'm using Android Instrumentation Tests, with tests under /androidTest, for tests that run headless on a continuous integration server. These are a mix of unit and functional tests. I need a separate context to run UI tests (the CI environment only runs headless), and another to run integration tests which hit production servers.
I had been using product flavors to satisfy the multiple context need, but that is obviously a mis-use of the mechanism and presents its own issues since product flavors don't currently propagate to submodules. My latest "brilliant idea" is to move all code but the Application class from the app module to an appcommon library module, then add multiple application modules to the AS project workspace. So, for example, the IntegrationTest module depends on all modules from the project except app and has its own Application.java file. Instead of the old style of having a test.apk that runs against an app.apk (frankly, I don't know exactly how that works), I get a single test.apk that includes all the tests from integrationtest/.../androidTest plus all the app code from the modules. So far, this seems to be working out pretty well. greg -- 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.
