You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is easy to get lost with dependencies management across different project modules (especially with libs versions). To make it easier, take a look at `buildsystem/dependencies.gradle` where everything is configured. Each module has separate configuration, with additional two for testing and annotation processing. Like some other patterns, this was originally introduced in [Azimo](https://azimo.com) Android application by [@dbarwacz](https://github.com/dbarwacz).
@@ -38,7 +38,7 @@ Here are some highlights from it:
38
38
39
39
For the rest take a look at the code - should be self-explaining. As this is just self-invented setup (that works on production!), all kind of feedback is warmly welcomed.
The repository contains shared configurations for running Unit Tests directly from Android Studio.
110
110
111
-

111
+

112
112
113
113
#### All tests at once
114
114
@@ -118,14 +118,14 @@ Recently it is not always possible to run all tests at once (see troubleshooting
118
118
119
119
Run `App and modules tests`. This configuration will run unit tests from all modules in separate tabs, one after another. To modify list of tests, click on `Edit Configurations` -> `App and modules tests` -> `Before Launch`.
There is a bug in Android Studio which prevents from launching all unit tests at once, before their code is generated (what happens after the first run of unit tests for every single module independently). For more take a look at Android Studio bug tracker: https://issuetracker.google.com/issues/111154138.
127
127
128
-

128
+

129
129
130
130
## Test coverage for unit tests
131
131
@@ -157,7 +157,7 @@ buildTypes {
157
157
158
158
* Task `testDebugUnitTestCoverage` depends on `testDebugUnitTest` tasks (each module separately). Thanks to it all sources required for coverage report are available before gradle starts generating it (in `<module_dir>/build/...`.
@@ -173,7 +173,7 @@ To run all Instrumentation tests from all modules at once launch emulator or plu
173
173
```
174
174
175
175
When all goes fine, you should see testing report in `app/build/reports/androidTests/connected/` directory.
176
-

176
+

177
177
178
178
### Functional vs End-to-end testing
179
179
From the high level, Android Instrumentation tests can be split into two types: functional and end-to-end. You can check my [article](https://medium.com/azimolabs/automated-testing-will-set-your-engineering-team-free-a89467c40731) about how we do QA at Azimo to see what is the difference between both of them.
@@ -195,3 +195,56 @@ It is, because `app` module doesn't have access to `RepositoryDetailsActivity` c
195
195
What about end-to-end tests? They shouldn't be problematic, simply because tests shouldn't have knowledge about specific implementation, but rather how user interface is composed (so again, not: `withText("R.string.show_repos")` but `withText("Show repositories")`).
196
196
197
197
More cases: TBD
198
+
199
+
200
+
## Proguard
201
+
202
+
Proguard configuration isn't very different in standard and multi-feature project configuration. Minification process is enabled in `app/build.gradle`[file](app/build.gradle):
For proguard configuration and know-how we could create completely separate demo project and a bunch of articles. Instead, just take a look at screenshots that compare apk files built from this project, with and without minification enabled.
It is also possible to Provide proguard configuration for each module separately. Why would you like to do this? Usually Proguard configuration is set in app's module gradle file. Also all global flags `-dontoptimize` also should be set there.
229
+
But sometimes there are module-specific configurations. So for example you would like to keep methods or classes, even if they aren't used in app's module. Also when you share .aar library file, you can provide it with Proguard configuration built in.
230
+
In this situation you should use `consumerProguardFiles`. For example, see `features/base/build.gradle` (file)[features/base/feature-base-proguard-rules.pro]:
-keep class com.frogermcs.multimodulegithubclient.base.BaseActivity {
244
+
public void notUsedMethod();
245
+
}
246
+
```
247
+
248
+
It means that method `notUsedMethod()` from class (BaseActivity)[features/base/src/main/java/com/frogermcs/multimodulegithubclient/base/BaseActivity.java] will be kept, no matter what.
249
+
250
+
For more details, take a look at [this blog post](https://proandroiddev.com/handling-proguard-as-library-developer-or-in-a-multi-module-android-application-2d738c37890) that describes how to setup Proguard for multi-module android app.
0 commit comments