Summary

Update for changes in fixture loading.

Review Request #14783 — Created Jan. 15, 2026 and submitted Feb. 12, 2026, 7:31 a.m.

Information

Owner

david

Repository

Djblets

Branch

release-5.x

Bugs

Depends On

Reviewers

Groups

djblets

People

Description

Django 5.2 made an un-announced change that moved fixture loading to

happen at class init time rather than per-test-method. As part of this,

the _load_fixtures method has been made a @classmethod. This is a

fundamentally better approach, but causes numerous problems with our own

fixture code.
This change updates our FixturesCompilerMixin to operate at class-time

rather than at test function time. This requires changing the way we

hide the fixtures classvar from the parent class, since

__getattribute__ can't work.
The @add_fixtures decorator is now a performance hit rather than a

performance benefit. In addition, the replace argument is no longer

possible (but luckily, nothing actually used that). I've added a warning

about the performance implications, but for now it's hidden behind an

environment variable because we use this decorator a lot.

Testing Done

Ran unit tests and verified that fixtures worked appropriately.

Commits

Summary	ID
Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr

Summary

Update for changes in fixture loading.

Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.

vozroonuuumnwwkwllsykxxkovwrwzsr

Issues

Description	From	Last Updated
redefinition of unused 'Sequence' from line 18 Column: 5 Error code: F811	reviewbot	Jan. 15, 2026, 3:22 p.m.
Is this still true with Django 5.2, now that they've moved to class init time instead of per test?	maubin	Feb. 10, 2026, 10:11 a.m.
These groups are in the wrong order.	chipx86	Feb. 11, 2026, 10:20 a.m.
The docs are missing the Returns.	chipx86	Feb. 11, 2026, 10:21 a.m.
Can you place the trailing ) on here and the next multi-line string on the following line, a la lists/dicts, …	chipx86	Feb. 11, 2026, 10:21 a.m.
So, I'm not sure we do want to remove this.. I believe we have a lot of tests across our …	chipx86	Feb. 11, 2026, 10:21 a.m.
This was previously missing a , optional.	chipx86	Feb. 11, 2026, 10:21 a.m.
For multi-line strings, can we move the ) to the following line, isolating the contents like we do multi-line lists/dicts? …	chipx86	Feb. 11, 2026, 10:21 a.m.

flake8 failed.

JSHint passed.

flake8

djblets/testing/testcases.py (Diff revision 1)
The issue has been dropped. Show all issues
```
redefinition of unused 'Sequence' from line 18

Column: 5
Error code: F811
```

Commits:

	Summary	ID
	Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr
	Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr

Diff:

Revision 2 (+372 -206)

Show changes

	djblets/testing/decorators.py
	djblets/testing/testcases.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

djblets/testing/testcases.py (Diff revision 2)

The issue has been dropped. Show all issues

Is this still true with Django 5.2, now that they've moved to class init time instead of per test?

david Feb. 10, 2026, 10:12 a.m.

Yeah. It's much better than when it was per method, but it still calls the loaddata command per fixture file per test case class.

Change Summary:

Move to release-5.x. It turns out that most things being @classmethod actually happened way back in Django 1.8 (!!!!) and we just never noticed.

I'll make a separate change for _fixture_setup() being a classmethod for Django 5.0+ for the release-6.x branch.

Commits:

	Summary	ID
	Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr
	Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr

Branch:

release-6.x

release-5.x

Diff:

Revision 3 (+374 -206)

Show changes

	djblets/testing/decorators.py
	djblets/testing/testcases.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

djblets/testing/decorators.py (Diff revision 3)
The issue has been resolved. Show all issues
```
These groups are in the wrong order.
```
djblets/testing/decorators.py (Diff revision 3)
The issue has been resolved. Show all issues
```
The docs are missing the Returns.
```

djblets/testing/decorators.py (Diff revision 3)

The issue has been resolved. Show all issues

Can you place the trailing ) on here and the next multi-line string on the following line, a la lists/dicts, so the string's self-contained?

djblets/testing/decorators.py (Diff revision 3)

The issue has been resolved. Show all issues

So, I'm not sure we do want to remove this.. I believe we have a lot of tests across our codebases that really do depend on fixtures being applied to specific tests, and would fail if we move all addfixture-specified tests down into the class. I think it'll be pretty messy.

I get there's a performance hit, but I think there's still value here.

djblets/testing/testcases.py (Diff revision 3)
The issue has been resolved. Show all issues
```
This was previously missing a , optional.
```

djblets/testing/testcases.py (Diff revision 3)

The issue has been resolved. Show all issues

For multi-line strings, can we move the ) to the following line, isolating the contents like we do multi-line lists/dicts?

Same with the sys.stderr.write below.

Commits:

	Summary	ID
	Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr
	Update for changes in fixture loading. Django 5.2 made an un-announced change that moved fixture loading to happen at class init time rather than per-test-method. As part of this, the `_load_fixtures` method has been made a `@classmethod`. This is a fundamentally better approach, but causes numerous problems with our own fixture code. This change updates our `FixturesCompilerMixin` to operate at class-time rather than at test function time. This requires changing the way we hide the `fixtures` classvar from the parent class, since `__getattribute__` can't work. The `@add_fixtures` decorator is now a performance hit rather than a performance benefit. In addition, the `replace` argument is no longer possible (but luckily, nothing actually used that). I've added a warning about the performance implications, but for now it's hidden behind an environment variable because we use this decorator a lot. Testing Done: Ran unit tests and verified that fixtures worked appropriately.	vozroonuuumnwwkwllsykxxkovwrwzsr

Diff:

Revision 4 (+382 -206)

Show changes

	djblets/testing/decorators.py
	djblets/testing/testcases.py

Checks run (2 succeeded)

flake8 passed.

JSHint passed.

Ship it!

```
Ship It!
```

Status:: Completed
Change Summary:: Pushed to release-5.x (3027dd5)