Integration testing docs and refactor (SC-746)

[TheRealFalcon]

Proposed Commit Message

Integration testing docs and refactor

* Include CI and Fixtures sections in integration test docs
* Incorporate additional variable annotations
* Remove unnecessary IntegrationInstance subclasses
* Move setup_image teardown into its fixture

Additional Context

[holmanb]

+1 This content is really helpful. I haven't spent much time reviewing the code since tests don't pass at the moment.

While we're updating the docs do you think it would be helpful to add some bullet points pointing out the "best practices" we are trying to follow that aren't exemplified in the codebase currently? Test classes/fixtures that are in use that we plan on removing, for example, are something that we don't really have documented but have come up in code reviews a few times recently that could potentially be documented.

[TheRealFalcon]

Test classes/fixtures that are in use that we plan on removing, for example, are something that we don't really have documented but have come up in code reviews a few times recently that could potentially be documented.

Only thing I can think of at the moment is the dated SRU marks...which...we should just remove (I can do as another commit on this PR). Any particular examples come to mind?

[holmanb]

Test classes/fixtures that are in use that we plan on removing, for example, are something that we don't really have documented but have come up in code reviews a few times recently that could potentially be documented.

Only thing I can think of at the moment is the dated SRU marks...which...we should just remove (I can do as another commit on this PR). Any particular examples come to mind?

Removing CiTestCase where possible is one thing that came to mind.

[TheRealFalcon]

Ooh, right. I tried to keep the scope of this PR to integration tests, whereas that's for unit tests, but that should definitely be addressed too.

[blackboxsw]

+1 on this a couple of suggestions

• In the Test Execution section of this page should we tell folks the expected behavior for test of their test env? We had questions in IRC today (and have had them in the past) with folks trying to use pip to install pycloudlib etc. might we worth telling them the tox -re integration-tests entry point or ./tools/tox-venv integration-tests to ensure they get the right versions of dependencies?
• minor flake8 failure
• Only one more sru_next mark to remove and I think you can @pytest.mark.sru_next from tests/integration_tests/bugs/test_lp1835584.py

Approve regardless of your decisions on sru_next and/or tox docs related to integration test env setup.