[internal] improve local testing experience

[pichlermarc]

A lot of the tests in this repository require some dependencies to run (postgres, mysql, redis).

By default, we skip a lot of tests since these dependencies need to be spun up manually. Usually, to run them locally an env var needs to be set that prevents these tests from being skipped. Unfortunately this is currently inconsistent across packages.

The goal of this issue is to streamline the testing setup and ensure scripts behave the same in each package, and add missing scripts if necessary:

• test:docker:start
  • spins up one or more docker containers which are used for testing, mapping ports if necessary
• test:docker:stop
  • stops the containers started by test:docker:start
• test:local
  • sets the necessary environment variables for the test
  • runs the tests

To keep review scope manageable, only work on one PR per package:

• @opentelemetry/instrumentation-memcached
• @opentelemetry/instrumentation-cassandra
• @opentelemetry/instrumentation-mongodb
• @opentelemetry/instrumentation-mongoose
• @opentelemetry/instrumentation-mysql
• @opentelemetry/instrumentation-mysql2
• @opentelemetry/instrumentation-tedious
• @opentelemetry/instrumentation-pg
• @opentelemetry/instrumentation-redis
• @opentelemetry/instrumentation-redis-4
• @opentelemetry/instrumentation-amqplib

Additional task (documentation):

Once all packages have been updated:

• document how to run local tests for a package in CONTRIBUTING.md. Since all scripts behave the same, it should be enough to mention the order of scripts to run.

Additional resources

• workflow which sets the environment variables for all tests

[pikalovArtemN]

Can i pick it ?

[pikalovArtemN]

And what do you think about Testсontainers ?

[pichlermarc]

@pikalovArtemN

thanks for volunteering. 🎉

And what do you think about Testсontainers ?

I've never used them directly so I'd have a few questions first:

• do they work in GitHub Workflows?
  • from experience it's cumbersome to spin up containers in CI, and if we add it to the test code directly I'd like to go for a unified approach (able to run both in CI and locally using testcontainers, alinging local and CI testing as closely as possible)
• Can image version updates be automated using renovate or similar?
  • Workflow files get automatically updated by renovate if needed, so when going for a unified approach it'd also be good if we could keep this
• How does this affect Windows/macOS users that may not use Docker Desktop but an alternative such as Podman or Colima? Can they still run it? Is there more (or less) extra configuration required for them compared to the approach outlined above? 🤔

[trentm]

Hi. I have a proposal for this at #2214

@pikalovArtemN I hope I didn't stomp on something you were working on already.

[pichlermarc]

This is essentially done. Thank you @david-luna for getting that over the finish line in #2886 🙂