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
Copy file name to clipboardExpand all lines: tests/conformance/README.md
+15-15Lines changed: 15 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,15 +4,15 @@
4
4
5
5
1.`tests/` directory contains the configuration and the test definition for conformance tests.
6
6
2. All the conformance tests are within the `tests/conformance` directory.
7
-
3. All the configurations are in the `tests/config` directory.
8
-
4. Each of the component specific `component` definition are in their specific `component type` folder in the `tests/config` folder. For example, the `redis` statestore component definition within `state` directory.
- Cloud specific components will be within their own `cloud` directory within the `component type` folder, e.g. `pubsub/azure/servicebus`.
7
+
3. All the components' configurations are in the `tests/config` directory.
8
+
4. Each of the component specific component's definition are in their specific `<component type>` folder in the `tests/config` folder. For example, the SQLite state store component definition is in the `tests/config/state/sqlite/` directory.
- Cloud-specific components will be within their own `<cloud>` directory within the `<component type>` folder, e.g. `tests/config/pubsub/azure/servicebus`.
11
+
- If a component has multiple variants, they are defined in sub-folders. For example, for the MySQL state store, `tests/config/state/mysql/mysql` contains the configuration for testing against MySQL, while `tests/config/state/mysql/mariadb` uses MariaDB.
11
12
5. Similar to the component definitions, each component type has its own set of the conformance tests definitions.
12
-
6. Each `component type` contains a `tests.yml` definition that defines the component to be tested along with component specific test configuration. Nested folder names have their `/` in path replaced by `.` in the component name in `tests.yml`, e.g. `azure/servicebus/topics` should be `azure.servicebus.topics`
13
-
7. All the tests configurations are defined in `common.go` file.
14
-
8. Each `component type` has its own `_test` file to trigger the conformance tests. E.g. `bindings_test.go`.
15
-
9. Each test added will also need to be added to the `component type/tests.yml` workflow file.
13
+
6. Each component type contains a `tests.yml` definition that defines the component to be tested along with component-specific test configuration. Nested folder names have their `/` in path replaced by `.` in the component name in `tests.yml`, e.g. `azure/servicebus/topics` should be `azure.servicebus.topics`
14
+
7. Each component type has its own `_test` file to trigger the conformance tests, e.g. `bindings_test.go`. This file contains also the test configurations.
15
+
9. Each test added will also need to be added to the `<component type>/tests.yml` workflow file.
16
16
17
17
## Conformance test workflow
18
18
@@ -24,21 +24,21 @@
24
24
25
25
1. Add the component specific YAML to `tests/config/<COMPONENT-TYPE>/<COMPONENT>/<FILE>.yaml`.
26
26
2. All passwords will be of the form `${{PASSWORD_KEY}}` so that it is injected via environment variables.
27
-
3. Register the component `New**` function in `common.go`. For example:
27
+
3. Register the component `New**` function in `<COMPONENT-TYPE>_test.go`. For example:
0 commit comments