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
WL#14254: Extended test suite with Docker environment
There is an extended set of tests distributed as part of the project
which are never executed within a regular test run. This is because
they require multiple MySQL server instances, or instances with a
specific configuration to be available.
Up until now, the testing infrastructure was optimized for a scenario
where it assumed that a MySQL server instance is available either in the
local system or on some other network-accessible host.
With the introduction of the Docker-based test setup in WL#15353, it is
now easier to address these limitations and migrate to a fully
container-based testing environment on top of something like Docker's
compose, where a testing container can communicate with other containers
that act as MySQL server instances and other service discovery
components enabling automated end-to-end tests for existing client
features such as Unix sockets, IPv6, TLS certificates, DNS SRV and
multi-host connections alongside effective regression and compatibility
testing with older MySQL versions.
This patch extends the existing Docker-based test setup to account for
all these scenarios, ensuring the full test suite can run in a
consistent and replicable setting.
Apart from the testing container, the setup now includes multiple
containers running MySQL server instances with different configurations.
Users are still allowed to run the default set of tests using an
instance available at a specific host. Otherwise, the tests run using
an instance on one of the containers, which is also used as a fallback
for tests using Unix sockets, on macOS, where it is not possible to
connect from the container to the host using that socket, or on Linux,
when the MYSQLX_SOCKET environment variable is not specified.
Change-Id: Ic7b4f524474ce527d047acff3ca8080bfbbc3f40
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+37-5Lines changed: 37 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -81,15 +81,19 @@ $ npm run test
81
81
$ npm run test:unit && npm run test:functional
82
82
```
83
83
84
-
#### Using a Docker container
84
+
#### Using Docker
85
85
86
-
Alternatively, for Linux or macOS users, there is a script that builds and runs a Docker container which then executes the test suite. This means no external dependency, apart from a running MySQL server, is needed.
86
+
Alternatively, for Linux or macOS users, there is a script that builds and launches a group of Docker containers as an environment where the automated test suite can execute without any additional dependency (apart from a Docker-based container engine).
87
87
88
-
The script uses the environment variables described previously and introduces a few new ones. These are mostly meant to be used for configuring the Docker container itself. They allow to specify the path to a Node.js engine image, the network proxy setup and the URL of the NPM registry to use.
88
+
There are three different set of containers. One, built on top of a Node.js Docker image, is responsible to execute the test suite and contains the source tree and all the required 3rd-party dependencies. Another one launches a small DNS proxy with service discovery capabilities that allows to test among other things, DNS SRV connections in a dynamic network. The DNS proxy is also responsible for linking an additional set of multiple containers running MySQL server instances using different versions and/or configuration options. These allow to run specific tests against older versions to check for regressions, ensure compatibility between authentication mechanisms and deprecated server-side authentication plugins, setup TLS certificate chains between client and server, and test multi-host capabilities and connection failover, end-to-end.
89
+
90
+
The script uses the environment variables described previously and introduces a few new ones. These are mostly meant to be used for configuring the Docker containers. They allow to specify the base Node.js and MySQL Docker images, the network proxy setup, and the URL of the NPM registry to use.
89
91
90
92
*`BASE_IMAGE` (`container-registry.oracle.com/graalvm/nodejs:latest` by default)
91
93
*`HTTP_PROXY` (value of the environment variable in the host by default)
92
94
*`HTTPS_PROXY` (value of the environment variable in the host by default)
95
+
*`MYSQL_IMAGE` (`mysql/mysql-server` by default)
96
+
*`MYSQL_VERSION` (`latest` by default)
93
97
*`NO_PROXY` (value of the environment variable in the host by default)
94
98
*`NPM_REGISTRY` (`https://registry.npmjs.org/` by default)
95
99
@@ -98,7 +102,7 @@ There is one additional environment variable called `TEST_PATTERN` which can be
98
102
Ultimately, the script allows an argument which identifies the underlying NPM script that gets executed. So, in theory, any of the available NPM scripts can be executed in the container, but by default, it will execute the `test` script.
99
103
100
104
```sh
101
-
# executing the default test script with the default environment (Linux only)
105
+
# executing the default test script with the default environment
Similar to when the tests run on a local environment, the `MYSQLX_HOST` variable is only relevant for the functional tests. On Linux, the variable is optional and the Docker container will run using the "host" network mode whilst tests assume the MySQL server is listening on `localhost`. On macOS, since containers run on a virtual machine, host loopback addresses are not reachable. In that case, the `MYSQLX_HOST` variable is required and should specify the hostname or IP address of the MySQL server.
115
+
Users are still able to run the default functional test suite using their own MySQL server instance. Similar to when the tests run on a local environment, the `MYSQLX_HOST` variable is only relevant for the functional tests. The variable is optional and the tests running in the Docker container assume the MySQL server is listening on the host machine and is reachable via `host.docker.internal`. If the MySQL server instance is not running in the host machine, the `MYSQLX_HOST` variable can specify the appropriate hostname or IP address. There is a fallback server instance running in one of the Docker containers which is reachable via `mysql.docker.internal`.
116
+
117
+
```sh
118
+
# executing the extended functional tests in the Docker environment
119
+
$ ./test/docker/run.sh test:functional:extended
120
+
# executing the default functional tests in the Docker environment
Due to some [know limitations](https://github.com/docker/for-mac/issues/483) on the macOS Docker architecture, Unix socket tests can only run on Linux. In that case, if the `MYSQLX_SOCKET` variable is explicitely specified, a shared volume between the host and the container will be created as a mount point from the socket file path in the host and an internal container directory specified as a volume, where the socket file path becomes available.
114
129
@@ -131,6 +146,23 @@ As a formal rule, a patch should not lead to a decrease of the overall code cove
131
146
132
147
Besides looking at the content generated via the standard output of your command line, you can also check the report available at `coverage/index.html` using a web browser.
133
148
149
+
Code coverage reports can also be generated in the Docker environment using the same set of NPM scripts.
150
+
151
+
```sh
152
+
# generate code coverage reports using the default test suite
153
+
$ ./test/docker/run.sh coverage
154
+
# generate code coverage reports using the unit test suite
155
+
$ ./test/docker/run.sh coverage:unit
156
+
# generate code coverage reports using the default functional test suite
157
+
$ ./test/docker/run.sh coverage:functional
158
+
# generate code coverage reports using the extended functional test suite
# generate code coverage reports using the full test suite
161
+
$ ./test/docker/run.sh coverage:functional:all
162
+
```
163
+
164
+
A `coverage` folder will be created in the project root directory containing the artifacts generated by the container, which are copied using a bind mount. If the folder already exists, the contents will be replaced.
165
+
134
166
### Code Style and Convention
135
167
136
168
Any change to the project's source code must also follow the standard set of code style/convention rules enforced by the existing tooling infrastructure. So, before submitting a patch, you can check if it violates any of those rules using the following:
0 commit comments