Title: Can I run an ORM module import in Django without setting up a database?
Tags: python,django,unit-testing,python-unittest

Question: in our application (a big monolith), we have a lot of "unit tests" that inherit from django TestCase. They are something like this:
from django.test import TestCase

class SomeTestCase(TestCase):
    def test_something(self):
        self.assertTrue(1)

Running this simple test in our codebase, it takes around 27 seconds. As you can say, this is a really high number given how simple is the code being run. Nonetheless, if instead we be just inherit from the TestCase from unittest module, like this:
from unittest import TestCase


class SomeTestCase(TestCase):
    def test_something(self):
        self.assertTrue(1)

The time needed goes down to 4 seconds. Which is still a little bit high, but you need to consider that we are using PyCharm connected to a docker compose environment, so there is a little bit of overhead in that side.
So what we want to achieve, is able to run tests just inheriting from unittest in the cases where we can, and inherit from django TestCase where we need some access to the ORM.
The main problem we have faced is imports of models. Everytime we try to run a test file inheriting just from unittest, there is an import somewhere of a django model, which triggers the following error:
django.core.exceptions.AppRegistryNotReady: Apps aren't loaded yet.

You may be thinking: oh, if you are importing in the test a model, then the code being tested must need a model so anyway you need the database. Well, this is not entirely true, because for instance, when we are mocking a service in the application layer, and that service contains a repository importing a model, then the repository is mocked and we cannot mock the repository without importing it, importing also the ORM dependency.
So, is there anyway to change this behaviour? Have you faced similar problems? All the posts I have read about speeding up django tests do not cover this problem, so maybe we are doing something weird that the rest of the people is not doing.
Ideally, we would only import from django TestCase when we are testing repositories or data sources, where we are coding an integration test between our code and the ORM.
Update
Some people suggestd to carefully design our system to avoid our logic having to import ORM code, but to be honest I have thought about this but I have not found any way of doing this. Let's see this example:
class SomeService:
    def __init__(self):
        self.repository = Repository()

and then the repository would be something like this:
from models import SomeModel

class Repository:
    pass

I cannot think of any way "good" of inverthing this import dependency. And this will also have the same problem in our controllers when we import the services.
Nonetheless, I have a couple of options:
Option 1: local imports
class Repository:
    from models import SomeModel
    self.model = SomeModel

I don't like this option because it resuls in a pretty weird code.
Option 2: Use Dependency Injection
class SomeService(SomeServiceInterface):
    def __init__(self, repository: RepositoryInterface):
        self.repository = repository

And the repository:
from models import SomeModel

class Repository(RepositoryInterface):
    pass

In a static configuration file, we could define the mapping between interfaces, like this:
di_register = {
"import path to interface": "import path to implementation"
}
Take into account that the use of strings is quite important to avoid python from actually running the import of the modules (which whould trigger the ORM problem). Now we just need a class to inject this automatically by inspecting the signature of the constructor (which we have done and implemented successfully, but I'm going to omit the code because is not needed for this question).
If we already have this solution, why are we looking for another, you may ask? Because some team members do not like the idea of creating an interface for every class we create, then having to register them in the configuration file and declare all dependencies as the signature of the constructor. Honestly, I like this approach, but given the opinion of other team members, I am looking for alternative solutions to this problem.

Answer: One solution here is to take a careful look at the design of your system. For example, you might have some logic that does not rely on the ORM at all. If you can isolate this logic into its own module that never imports your models. Then you can test it without worrying about the costs importing the ORM.