The easiest way to control the order in which fixtures are executed, is to just request the previous fixture in the later fixture. So to make sure b runs before a: @pytest.fixture(autouse=True, scope=”function”) def b(): pass @pytest.fixture(scope=”function”) def a(b): pass For details on the general fixture resolution order, see Maxim’s excellent answer below or have … Read more
Fixture scheduling is a well known problem. This is python implementation of algorithm given at: http://en.wikipedia.org/wiki/Round-robin_tournament # generation code – for cut and paste import operator def fixtures(teams): if len(teams) % 2: teams.append(‘Day off’) # if team number is odd – use ‘day off’ as fake team rotation = list(teams) # copy the list fixtures … Read more
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
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