Something to consider is that you're testing functionality that you didn't write. Part of deferring to the ImporterConfigMixin is that you can be reasonably unaware of how it works and if it changes. The unit tests for the mixin should have (and do in this case) covered testing each individual option, meaning a lot of this can be skipped in favor of you only testing your contract with the mixin. That is to say, you subclass it, call it's constructor, and call it's create config method. IMO, ensuring each option is properly handled doesn't fall under this test case's jurisdiction. It's handled on faith that the mixin is unit tested and works properly (acknowledging that the level of faith you have is a subjective thing).

This ends up being a lot of repetition, especially in this case given the sheer amount of options. It's also inflexible. If a new option is added to the mixin, it will be covered in those tests but not these, leading to a bizarre state in this test of (re)testing most but not all of the mixin's functionality.

I don't always follow that policy myself, but in this case given the amount of work that had to go into it, it could have been avoided.