I’ve specified path relative to project root in the TestCase like so: from django.test import TestCase class MyTestCase(TestCase): fixtures = [‘/myapp/fixtures/dump.json’,] … and it worked without using FIXTURE_DIRS
I think I figured out a way to do this. There is a ‘raw’ parameter in the kwargs passed in along with signals so I can replace my test above with this one: if (kwargs.get(‘created’, True) and not kwargs.get(‘raw’, False)): Raw is used when loaddata is running. This seems to do the trick. It is … Read more
When using pytest fixture with mock.patch, test parameter order is crucial. If you place a fixture parameter before a mocked one: from unittest import mock @mock.patch(‘my.module.my.class’) def test_my_code(my_fixture, mocked_class): then the mock object will be in my_fixture and mocked_class will be search as a fixture: fixture ‘mocked_class’ not found But, if you reverse the order, … Read more
Use “pk: null” instead of “pk: 1” (or whatever), which will result in the PK being set to None, and when the object is saved a primary key will be assigned. This works for YAML at least, I’m guessing you’re using that if you are creating by hand.
To dump data: python manage.py dumpdata app.model_name –indent 4 > fixtures/model_name.json To load data: python manage.py loaddata fixtures/model_name.json –app app.model_name –indent X is optional.
manage.py dumpdata –natural will use a more durable representation of foreign keys. In django they are called “natural keys”. For example: Permission.codename is used in favour of Permission.id User.username is used in favour of User.id Read more: natural keys section in “serializing django objects” Some other useful arguments for dumpdata: –indent=4 make it human readable. … Read more
This is actually supported natively in py.test via indirect parametrization. In your case, you would have: @pytest.fixture def tester(request): “””Create tester object””” return MyTester(request.param) class TestIt: @pytest.mark.parametrize(‘tester’, [[‘var1’, ‘var2’]], indirect=True) def test_tc1(self, tester): tester.dothis() assert 1
I think you’re referring to test fixtures: The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable. Some people call this the test context. Examples of fixtures: Loading a database with a specific, known set of data … Read more