Fix: Tox Testing Suite to run in Randomized Order

[ronnathaniel]

Description

Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.

Testing allows product creators to verify the functionality of that product. A testing suite during phases of CI/CD can prevent bugs from ever reaching end users.

Should the testing results be inaccurate, and the creators have now lost all insight into their product. What this change does is add a layer of security into the testing suite, randomizing the order in which tests are run. Up until now, a UnitTest child-class would have functions A, B, and C, and they would be run in order A->B->C. With this change, the order of tests would be randomized, based on a seed of the current unixtime. Essentially in the form of (3c1)->(2c1)->(1c1), using the example of A, B, and C.

Why does this add a layer of security? It allows us to immediately spot which test are dependent on others, as these very test fail during this migration to a random testing order. A test that is dependent on another is not a test by itself, but moreso simply an extension of the dependency test.

Upon adding pytest-randomly plugin into Tox's environment, we see that the immediate failure of tests proves that many tests are dependent on others, and our current testing suite is flawed.

Dependency added: pytest-randomly to testenv.

Fixes #2760

Type of change

Please delete options that are not relevant.

• [X] Bug fix (non-breaking change which fixes an issue)
• [X] New feature (non-breaking change which adds functionality)
• [X] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [X] This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

This fix is different than most proposed tests/features. After the migration to a fully randomized testing environment, the sheer fact of all tests passing and working as expected proves that the testenv has returned to its "normalcy" and proper functionality.

• [X] Test A

exporter/opentelemetry-exporter-zipkin-json Has been the main package inspected during development

Does This PR Require a Contrib Repo Change?

Answer the following question based on these examples of changes that would require a Contrib Repo Change:

• The OTel specification has changed which prompted this PR to update the method interfaces of opentelemetry-api/ or opentelemetry-sdk/

• The method interfaces of test/util have changed

• Scripts in scripts/ that were copied over to the Contrib repo have changed

• Configuration files that were copied over to the Contrib repo have changed (when consistency between repositories is applicable) such as in

  • pyproject.toml
  • isort.cfg
  • .flake8

• When a new .github/CODEOWNER is added

• Major changes to project information, such as in:

  • README.md
  • CONTRIBUTING.md

• [ ] Yes. - Link to PR:

• [X] No.

Checklist:

• [X] Followed the style guidelines of this project
• [ ] Changelogs have been updated
• [X] Unit tests have been added
• [ ] Documentation has been updated