Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smoke unit test for redis migrations #9117

Open
wants to merge 25 commits into
base: develop
Choose a base branch
from

Conversation

archibald1418
Copy link
Contributor

@archibald1418 archibald1418 commented Feb 18, 2025

Motivation and context

Basic coverage for redis migrations support from #8898

How has this been tested?

Prepare

  • A .py migration file with class Migration is generated for each test in the directory of a django application
  • The migration file's Migration.run classmethod is patched with unittest.Mock to assert mock_calls from the migration tool to confirm that the migration was discovered and applied
  • Redis is patched with fakeredis instance throughout the whole test suite since our main concern is the migration tool itself, not the Redis database.

Case 1: Migration is added and applied successfully

  • Generate a correct stub file named 000_first.py with the following contents:
from cvat.apps.redis_handler.migration_loader import BaseMigration

class Migration(BaseMigration):
    @classmethod
    def run(cls): ...

In order for the stub to be discoverable by the migration tool, its name should start with numbers and it should contain a class Migration which is a subclass of BaseMigration.

  • Patch run method with a mock.
  • Call django's migrateredis.py script with django.management.call_command('migrateredis')
  • Assert that engine.001_cleanup_scheduled_jobs and redis_handler.001_first are added as members to Redis set cvat:applied_migrations
  • Assert that our run mock was called once

Case 2: Migration is not added and not applied

  • Flush fakeredis after previous case
  • Generate a bad stub file named 000_second.py with the following contents:
class Migration:
    @classmethod
    def run(cls): ...

Since the Migration class is not a subclass of BaseMigration, we expect that

  • LoaderError is raised
  • cvat:applied_migrations is an empty set
  • Migration.run is not called

Checklist

  • I submit my changes into the develop branch
  • I have created a changelog fragment
  • I have updated the documentation accordingly
  • I have added tests to cover my changes
  • I have linked related issues (see GitHub docs)

License

  • I submit my code changes under the same MIT License that covers the project.
    Feel free to contact the maintainers if that's a concern.

Oleg Valiulin added 2 commits February 18, 2025 22:03
@codecov-commenter
Copy link

codecov-commenter commented Feb 18, 2025

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 73.25%. Comparing base (de42098) to head (3942315).

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #9117      +/-   ##
===========================================
+ Coverage    73.18%   73.25%   +0.06%     
===========================================
  Files          446      447       +1     
  Lines        45661    45666       +5     
  Branches      3907     3907              
===========================================
+ Hits         33418    33451      +33     
+ Misses       12243    12215      -28     
Components Coverage Δ
cvat-ui 77.06% <ø> (-0.03%) ⬇️
cvat-server 70.18% <100.00%> (+0.14%) ⬆️

self.addCleanup(self.test_migration.cleanup)

call_command("migrateredis")
exp_migrations = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Could you please explain the purpose of generation test migration? why existing migrations are not enough? I do not really think that we need to modify/add files from cvat/apps when running tests. Otherwise, the generated files may not be removed e.g. when we stop debugging before cleanup is called.
  • Do I understand correctly that we need to update this test each time when a new Redis migration is added?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the existing migration files are correct, which means I cannot test a scenario where the tool throws LoaderError.
Though, case 1 could be rewritten to use existing migration files

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to update this test each time when a new Redis migration is added?

I didn't get it, why would that be the case? Tests are using fake Redis database

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't get it, why would that be the case? Tests are using fake Redis database

I'm talking about the case when we add one more redis migration. In that case the self.assertEqual(conn.smembers("cvat:applied_migrations"), exp_migrations) will fail. Please, check that the expected by the test migration keys are added to cvat:applied_migrations instead of comparing all set members.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes totally makes sense, applied

self.assertEqual(conn.smembers("cvat:applied_migrations"), exp_migrations)
self.test_migration.runner_mock.assert_called_once()

def test_migration_not_applied(self, redis1, _):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess the more appropriate test should cover a case when migrateredis is called with --check arg.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense

BAD_MIGRATION_FILE_CONTENT = MIGRATION_FILE_CONTENT.replace("(BaseMigration)", "")

with (
patch(f"{__name__}.MIGRATION_FILE_CONTENT", new=BAD_MIGRATION_FILE_CONTENT),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks a bit odd to me that you patch MIGRATION_FILE_CONTENT defined in the current module and not used anywhere else.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense, reworked the class to only generate bad migration

MUT = "cvat.apps.redis_handler"


@patch(f"{MUT}.migration_loader.Redis", return_value=fakeredis.FakeRedis())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need to patch it? It is used only as type annotations in the migration_loader module.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes you're right, removing this


from .utils import path_to_module

WORKDIR = PosixPath("cvat/apps")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Path? Tests can be run on windows

from pathlib import PosixPath


def path_to_module(path: PosixPath) -> str:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Path?

self.patcher: _patch = patch.object(self.test_class, "run")
self.runner_mock: Mock | None = self.patcher.start()

self.exp_migration_name = app_name + "." + self.make_migration_name()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, why did you decide not to check whether engine.001_cleanup_scheduled_jobs is added to cvat:applied_migrations after running migrateredis?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I misunderstood, I thought --check would be enough for this. Applying

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I reworked it to this: now the it looks for all cvat/apps/**/redis_migrations/[0-9]*.py files, extracts the expected migration names and asserts they are identical to members of cvat:applied_migrations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants