mirror of
https://github.com/material-components/material-components-android.git
synced 2026-01-19 19:41:35 +08:00
69a70219ad
Bazel wants a structure where the application used for testing and the tests themselves are in separate packages (which gradle is less picky about). Android has a gradle plugin for this setup (com.android.test), although it unfortunately has seemingly worse Android Studio support at this point. In any case, this change splits the code up a bit more, into 3 parts: - lib: the files we actually distribute as a library to end users - testing: the test application and its custom component subclasses that are tested by the emulator tests - tests: the actual emulator test code The structure is a tad strange for typical gradle projects (testing in particular, which has a build.gradle file for each individual Java package, at the same level as the actual source files), but it better matches the conventions of bazel while also avoiding the need for a ton of parallel directory structures at the top level. Known issues as of this commit: - Android Studio doesn't think the Java files in testing/ have the right package. I tried to fix this by bumping their java srcDir up to the java/ root and changing the includes, but Android studio seems unable to properly figure that out and instead acted like the Java files didn't exist at all, so I reverted that. We can possibly modify the iml files that get generated, but I'll save this for a follow-up commit since this is already very large. - Android Studio seems unable to run emulator tests properly (but they work from the command-line). I don't quite know why they fail, but seems like lacking support for the com.android.test plugin. Hopefully this is something we can work around for find a fix for in the near future. PiperOrigin-RevId: 146940681
172 B
172 B
tests
This directory contains the sources for the emulator tests for this library, which exercises a test application located in the ../testing directory.