The slowest part of Touchstone tests is spinning up everything in Docker. While it's unlikely anything can be done about that for the services themselves, the mocks could likely be made long-running, provided some way to sandbox multiple instances of mock usage in the same container. Instead of spinning them up on demand Touchstone would have a client-server model in which an instance is running/managing mock containers and other instances connect to that.
RabbitMQ
Implementing this for Rabbit should be pretty easy. Virtual hosts! ${TS_RABBITMQ_VHOST} = randomized ID
MySQL
MySQL could probably implement this as multiple databases. Multiple databases are already supported, only, their names are hardcoded. So it looks like this…
Now
mysql.yml
databases:
- name: a
statements:
# any statements, or maybe migrations handle the main DB
- name: b
statements:
# lots of statements
If Wiremock supports using multiple ports and treating them like virtual hosts, then this is trivial, like Rabbit but without any change required for service configuration.
If not, there are a couple options:
Context Root
Instead of aiming at http://${TS_HTTP_HOST}:${TS_HTTP_PORT}/, aim at http://${TS_HTTP_HOST}:${TS_HTTP_PORT}/${TS_HTTP_ROOT} and a randomized ID (followed by /) for TS_HTTP_ROOT is used to sandbox all the mocks for a given instance. Plus, most services should be pointed at ${TS_HTTP_URL} anyway, which would get the root added to it without the service needing to be reconfigured at all!
Routing
Create a sandboxing root as above on the Wiremock side; however, for ease of use…
Stand up a simple routing server that sends each port to its respective root without needing to add the root to the URL.
The slowest part of Touchstone tests is spinning up everything in Docker. While it's unlikely anything can be done about that for the services themselves, the mocks could likely be made long-running, provided some way to sandbox multiple instances of mock usage in the same container. Instead of spinning them up on demand Touchstone would have a client-server model in which an instance is running/managing mock containers and other instances connect to that.
RabbitMQ
Implementing this for Rabbit should be pretty easy. Virtual hosts!
${TS_RABBITMQ_VHOST}
= randomized IDMySQL
MySQL could probably implement this as multiple databases. Multiple databases are already supported, only, their names are hardcoded. So it looks like this…
Now
Instead
However, instead of using those names, a randomized ID is generated and used, and a variable
TS_MYSQL_DB_<capitalized_name>
is set to that ID.HTTP
If Wiremock supports using multiple ports and treating them like virtual hosts, then this is trivial, like Rabbit but without any change required for service configuration.
If not, there are a couple options:
Context Root
Instead of aiming at
http://${TS_HTTP_HOST}:${TS_HTTP_PORT}/
, aim athttp://${TS_HTTP_HOST}:${TS_HTTP_PORT}/${TS_HTTP_ROOT}
and a randomized ID (followed by/
) for TS_HTTP_ROOT is used to sandbox all the mocks for a given instance. Plus, most services should be pointed at${TS_HTTP_URL}
anyway, which would get the root added to it without the service needing to be reconfigured at all!Routing
Create a sandboxing root as above on the Wiremock side; however, for ease of use…
Stand up a simple routing server that sends each port to its respective root without needing to add the root to the URL.