Add integration test framework

[mishaschwartz]

Overview

This update adds a framework for testing the deployed stack using pytest. This will allow developers to check
that their changes are consistent with the existing stack and to add additionally tests when new functionality
is introduced.

Changes to implement this include:

• existing unit tests are moved to the tests/unit/ directory
• new integration tests are written in the tests/integration/ directory. More tests will be added in the
  future!
• conftest.py scripts updated to bring the stack up/down in a consistent way for the integration tests.
• unit tests updated to accomodate new testing infrastructure as needed.
• unit tests updated to test logging outputs better
• birdhouse interface script updated to support testing infrastructure (this should not change anything for
  other end-users).
• additional documentation added to birdhouse interface to improve user experience.
• docker healthchecks added to more components so that the readiness of the stack can be determined with or
  without the use of the canarie-api component.
• deprecates the optional-components/wps-healthchecks component since the healthchecks are now added by default
  to all WPS components.

Next steps:

• add more integration tests as needed
• add a framework for testing migrating the stack from one version to another

Changes

Non-breaking changes

• Adds integration tests and healthchecks

Breaking changes

• None

Related Issue / Discussion

• Introduces a mechanism for testing the stack locally so that we don't need to rely on integration tests run by notebooks through Jenkins. Since the Jenkins CI tests have been broken lately.
• This also gives developers a mechanism to tests their work locally and establishes a simple way to write integration tests (without the need to wrap them in jupyter notebooks).
• This PR only introduces the framework for creating these tests. Once this is approved, the actual work of writing the tests can start.
• Further discussion/planning is needed if we want to eventually run these tests in the CI pipeline

Additional Information

CI Operations

birdhouse_daccs_configs_branch: master
birdhouse_skip_ci: false

[tlvu]

Very interesting PR. Just my just pass. I'll come back.

[tlvu]

one more minor comment

[fmigneault]

Nice PR!

[fmigneault]

If $(print_config_command) was used, wouldn't if [ -z "$1" ]; then work the same?

Just curious. no-suffix is fine, but seems like a roundabout way with unnecessary hardcoded values.

[mishaschwartz]

By using a constant like 'no-suffix', it allows us to easily add other options in the future as well. For this specific use case [ -z "$1" ] would work as well but it's not as friendly to future developers.

I also like no-suffix because it's self-documenting 🤷

[fmigneault]

Ideally we should use an internal endpoint/port to avoid loop-back requests.

Also, consider using another endpoint such as the /version, since the root path gets redirected to whichever "frontend" entrypoint is defined, which might be inconsistent or pinging another redirected service from the stack.

[mishaschwartz]

I like the idea to an internal endpoint.

Just a note: curl won't follow redirects unless the --location flag is used so we don't have to worry about redirects to inconsistent places in this case.

So something like curl --fail http://localhost is sufficient because either it will redirect (success) if the nginx component is working or will fail if it isn't.

[tlvu]

Other than the minor NO_COLOR left, great PR !

[tlvu]

I haven't seen usage of this new fixture. In fact, same for most of the new fixtures here.

I am guessing you are simply setting up for the future?

[mishaschwartz]

Fixtures with autouse=True are used automatically in tests within their scope. So you won't see most of these referenced explicitly in tests (but they are being used!).

[tlvu]

OH ! Interesting!

[fmigneault]

Just needs a line to changelog about the deprecated wps-healthchecks.