| # flink-architecture-tests-test |
| |
| This submodule contains rules defined centrally for test code architectural tests that will be |
| developed in each submodule individually where the test code has been developed. |
| |
| ## Why the architecture test infra for production code and for test code are different |
| |
| Compared to `flink-architecture-tests-production` which implements and executes architectural rules |
| centrally, `flink-architecture-tests-test` implements the rules centrally, but they are executed |
| individually in each submodule. This is done for the following reasons: |
| |
| - Reduce the classpath complexity. In order to execute the tests centrally, each submodule would |
| have to provide a test-jar. However, this does not work well in IntelliJ which doesn't support all |
| Maven configurations (such as exclusion filters); this would cause the rules to behave differently |
| when executed from Maven versus IntelliJ. Furthermore, creating more test-jars is not desirable |
| and increases the project complexity. |
| - Separation of concerns. Test code should be viewed as internal to a module, and by separating the |
| violation stores for each submodule this separation can be maintained. Unlike the production code |
| tests there is few shared code between test code, and thus the performance benefits do not apply. |
| - Flexibility. Each submodule can not only import the generic rules defined |
| in `flink-architecture-tests-test` centrally, but also develop further module-specific |
| architectural tests locally. |
| |
| ## How do I write a new architectural rule? |
| |
| Please refer to [README](../README.md). |
| |
| ## How do I initialize and develop the first architectural test for a Flink submodule's test code? |
| |
| If there already exists any architectural test in the Flink submodule, you can skip this section and |
| start writing your architectural tests and rules. |
| |
| It is recommended to stick to the following template to setup and develop the first test code |
| architectural test for a Flink submodule. |
| |
| Under a Flink submodule where no architectural test has ever been developed. |
| |
| - Create `archunit.properties` and `flink-connector-file` under "<Flink Submodule> |
| /src/test/resources". Please use [archunit.properties](./src/test/resources/archunit.properties) |
| and [log4j2-test.properties](./src/test/resources/log4j2-test.properties) as template. |
| - Develop ArchUnit test under the package `org.apache.flink.architecture`. It is recommended to |
| use `TestCodeArchitectureTest` as the class name. |
| - Include the common tests |
| via `@ArchTest public static final ArchTests COMMON_TESTS = ArchTests.in(TestCodeArchitectureTestBase.class)` |
| . |
| - Develop individual rules under the package `org.apache.flink.architecture.rules` if it is |
| required. |
| |
| For practice purpose, please refer to the `flink-connector-file` as the reference implementation. |
| |
| ## What should I do if the tests fail? |
| |
| Please refer to [README](../README.md). |
| |
| ## How do I test Scala classes? |
| |
| Please refer to [README](../README.md). |
| |
| ## What should I do if I modify an existing rule? |
| |
| In that case, you need to regenerate all the stores. Just run this on the root of the project: |
| |
| ``` |
| rm -rf `find . -type d -name archunit-violations` |
| mvn test -Dtest="*TestCodeArchitectureTest*" -DfailIfNoTests=false -Darchunit.freeze.refreeze=true -Darchunit.freeze.store.default.allowStoreCreation=true -Dfast |
| ``` |