Fix unit tests with registry-backed SCMTools.

Review Request #12390 — Created June 20, 2022 and submitted — Latest diff uploaded

Information

Review Board
release-5.0.x

Reviewers

We hit some confusing issues when running selective Review Board test
suites with the introduction of registry-backed SCMTools.

Basically, when exclusively running certain test suites (ones that do
not use the test_scmtools fixture on the class level, but do add it
for selective tests through the use of @add_fixtures -- for instance,
./reviewboard/webapi/tests/test_review.py), we'd end up in a state
where the fixture would try to apply on top of tools injected into the
database through the registry. This is actually more the "correct"
behavior, as opposed to test_scmtools applying on top of nothing, but
it's the case that broke tests.

The problem has to do with registry setup, when the registry adds to the
database, and when fixtures load. The process is this:

  1. The first thing a test suite does is call Django's setUpClass(),
    then load class-defined fixtures, then call _fixture_setup() (which
    we override to compile and load fixtures -- too late and redundant on
    modern Django), and then setUp().

  2. Any test_scmtools fixtures are injected in Django's setUpClass().
    This gives us a common database entries used by all tests in the
    suite (using transactions/rollbacks to get back to that state). If
    that fixture is not used, no entries will be in the database for
    these tests.

  3. We register some test tools in our own setUpClass(), which triggers
    registry population. If test_scmtools was used, this does
    effectively nothing (though it will register entrypoint-provided
    tools). If it was not used, then this will inject its own common
    Tools entries in the database.

  4. We then get to our _fixture_setup(), which used to be where Django
    managed fixtures on a per-test basis. Djblets overrides this to do
    fixture compilation and loading (which doesn't work as well with
    modern Django) and loading of anything provided by @add_fixtures().
    Once again, any fixtures are loaded and injected into the database.
    If test_scmtools is used here, this is almost a no-op, as
    loaddata (which loads the fixtures) will ignore any identical
    matches in the database. If test_scmtools is not used on the class
    level, nothing happens here.

  5. Now we get to @add_fixtures(). This will try to incrementally add
    the fixtures to the database. If used on a test function, the
    _fixture_setup() for that call will load in any fixtures provided.
    If we use test_scmtools here and on the class level, nothing
    happens, since loaddata will see the data is the same. However, if
    the initial state was populated by the registry, this will fail, as
    the data won't match up. It'll conflict.

There's a bit of a chicken-and-egg problem here. Confusing, but the
solution is to treat our registry as the source of the fixture:

  1. The test_scmtools fixture is now empty. The fixture itself must
    remain for compatibility reasons, but it no longer needs content.
    It's simply an identifier.

  2. The SCMTools registry has a new function for the database population,
    called populate_db(). This is still called by populate(), but
    we're able to use it to force a re-sync of tools.

  3. TestCase.load_fixtures() (called by _fixture_setup()) now looks
    for test_scmtools, removes it from consideration, and then tells
    the registry to populate via populate_db(). This gives us one
    source of truth, and one place (setUpClass()) to manage suite-wide
    population of registered SCMTools.

All unit tests passed.

Ran selective unit test suites and individual tests that were previously
failing. They now pass.

Commits

Files