pytests failing with test_create_model_with_contenttype_field

[codehelp]

After updating to package 1.5.0 for Debian, the previously working call to the tests is failing:

PYTHONPATH=. pytest-3 -s -vv tests/

Expected behavior

I expected that the tests would pass in the same way as with 1.4.0

Actual behavior

tests/test_baker.py::TestHandlingContentTypeFieldNoQueries::test_create_model_with_contenttype_field FAILED

========================================================================================== FAILURES ==========================================================================================
_______________________________________________________ TestHandlingContentTypeFieldNoQueries.test_create_model_with_contenttype_field _______________________________________________________
tests/test_baker.py:627: in test_create_model_with_contenttype_field
    dummy = baker.prepare(models.DummyGenericForeignKeyModel)
model_bakery/baker.py:185: in prepare
    return baker.prepare(_save_related=_save_related, **attrs)
model_bakery/baker.py:404: in prepare
    return self._make(**params)
model_bakery/baker.py:457: in _make
    self.model_attrs[field.name] = self.generate_value(
model_bakery/baker.py:701: in generate_value
    return generator(**generator_attrs)
model_bakery/random_gen.py:208: in gen_content_type
    return ContentType.objects.get_for_model(choice(apps.get_models()))
/usr/lib/python3/dist-packages/django/contrib/contenttypes/models.py:51: in get_for_model
    ct = self.get(app_label=opts.app_label, model=opts.model_name)
/usr/lib/python3/dist-packages/django/db/models/manager.py:85: in manager_method
    return getattr(self.get_queryset(), name)(*args, **kwargs)
/usr/lib/python3/dist-packages/django/db/models/query.py:431: in get
    num = len(clone)
/usr/lib/python3/dist-packages/django/db/models/query.py:262: in __len__
    self._fetch_all()
/usr/lib/python3/dist-packages/django/db/models/query.py:1324: in _fetch_all
    self._result_cache = list(self._iterable_class(self))
/usr/lib/python3/dist-packages/django/db/models/query.py:51: in __iter__
    results = compiler.execute_sql(chunked_fetch=self.chunked_fetch, chunk_size=self.chunk_size)
/usr/lib/python3/dist-packages/django/db/models/sql/compiler.py:1173: in execute_sql
    cursor = self.connection.cursor()
/usr/lib/python3/dist-packages/django/utils/asyncio.py:33: in inner
    return func(*args, **kwargs)
/usr/lib/python3/dist-packages/django/db/backends/base/base.py:259: in cursor
    return self._cursor()
/usr/lib/python3/dist-packages/django/db/backends/base/base.py:235: in _cursor
    self.ensure_connection()
E   Failed: Database access not allowed, use the "django_db" mark, or the "db" or "transactional_db" fixtures to enable it.

Reproduction Steps

As expected, patching in the @pytest.mark.django_db for that function simply changes the failure to Failed: DID NOT WARN. which defeats the point of the test.

I could skip this test in the package build if the error message is too awkward to predict but it would be better to let it run, if possible.

platform linux -- Python 3.10.4, pytest-6.2.5, py-1.10.0, pluggy-1.0.0
PyQt5 5.15.6 -- Qt runtime 5.15.2 -- Qt compiled 5.15.2
rootdir: /home/neil/Documents/freexian/model-bakery/python-model-bakery-1.5.0, configfile: setup.cfg
plugins: qt-4.0.2, xvfb-2.0.0, cov-3.0.0, django-3.5.1

Versions

Python: 3.10.4 (also tested with 3.9.2)
Django: 3.2.13
Model Bakery: 1.5.0

Pytest 6.2.5
Pytest -django 3.5.1

[amureki]

@codehelp thanks for the report!

I am noticing old version of pytest-django package, which is not matching ones that were pinned for model-bakery 1.5.0:
https://github.com/model-bakers/model_bakery/blob/1.5.0/requirements_dev.txt#L14

I did install this version and indeed mentioned test fails with given traceback. I assume, there was some internal bug or change that was not allowing proper with pytest.warns construction. This is changed and working as "expected with pytest-django 4.5.2+.

May I suggest running your test suite against pinned dev dependencies?

pip install -r requirements_dev.txt

Best,
Rust

[amureki]

Hey @codehelp ! I'd go ahead and will close this issue, since I did not get any response to my proposal here.

Please take a look at it at your time and if there is still something wrong, approach me in this or a new issue.

Cheers,
Rust