[Testing] Settings with Model choices get data from DB, not test data

[LavissaWoW]

Please verify that this bug has NOT been raised before.

• [X] I checked and didn't find a similar issue

Describe the bug*

Writing some tests for a setting that has its choices set based on Group names, I found that the InvenTreeSettings pull their validation data from the DB, and not from test data when running tests.

Steps to Reproduce

1. A setting with 'choices': [(x.name, x.name) for x in Group.objects.all()]
2. Within a test, print(InvenTreeSetting.get_setting_choices('THE_SETTING')) returns data from the dev/prod DB, not the test data.

Expected behaviour

Populate settings using models with test data, not DB data

Deployment Method

• [X] Docker
• [ ] Package
• [ ] Bare metal
• [ ] Other - added info in Steps to Reproduce

Version Information

0.15.0 dev

Please verify if you can reproduce this bug on the demo site.

• [ ] I can reproduce this bug on the demo site.

Relevant log output

No response

[LavissaWoW]

Given a setting:

'THE_SETTING': {
    'name': _('SOME_SETTING_INFO'),
    'description': _('Find some group for this setting'),
    'choices': [(x.name, x.name) for x in Group.objects.all()]
}

Within a test method: Running print("Choices", InvenTreeSetting.get_setting_choices('THE_SETTING')) Returns Choices [('readers', 'readers'), ('engineering', 'engineering'), ('all access', 'all access'), ('test123', 'test123')]

From the test's model: Running print("All groups", Group.objects.all()) Returns All groups <QuerySet [<Group: my_test_group>]>

[SchrodingersGat]

This is probably because the 'choices' are evaluated at module load time, not at 'run time'. To get around this we would have to make 'choices' point to a callable function which gets called as required.

[LavissaWoW]

I moved the offending part into its own function, and that fixed the illustrated problem.

But the question at the core still stands: The production DB is accessed on load, even though tests clearly state in the console Creating test database for alias 'default'... Should we do something, or is it such a fringe case that awareness is enough of a fix?

[SchrodingersGat]

Ok, I think I had missed that subtlety in your original post. That is very strange indeed. I think it would be worth digging into.

[github-actions[bot]]

This issue seems stale. Please react to show this is still important.

[SchrodingersGat]

@LavissaWoW did you ever get any further with looking into this mystery?