Currently, when a test class inherits from ChannelsLiveServerTestCase, all database changes that happen will be written to the default main database, not the test database that is created by the parent class--TransactionTestCase. This is the reason that fixtures are not currently referenced
When ChannelsLiveServerTestCase initiates a DaphneProcess, by calling this following line
self._server_process = self.ProtocolServerProcess(self.host, get_application)
This instantiates a DaphneProcess object which is a multiprocessing.Process object which takes care of creating a new process. This uses the SpawnProcess of multiprocessing class on Windows and macOS. Linux uses the Fork method, but Fork causes problems. Spawn should be used only.
Here is what is said about spawn.
The parent process starts a fresh python interpreter process. The child process will only inherit those resources necessaryto run the process objects run() method. In particular, unnecessary file descriptors and handles from the parent processwill not be inherited. Starting a process using this method is rather slow compared to using fork or forkserver. [Available onUnix and Windows. The default on Windows and macOS.]
This means that django setup() is called and the settings file it reloaded. This means that `setting.DATABASES['default'] in the process that runs the Daphne server will point to the default database. This is incorrect, and will cause a leakage of all changes made by selenium or another testing framework.
Because ChannelsLiveServerTestCase inherits from TransactionTestCase, it it necessary that all functionality is retained. Therefore, we must point the django module at the test database in the the new process that is running Daphne so that we can correctly use the fixtures, and have the test database removed after testing is finished. Also, so that changes do not leak into the default database.
This is why, we reassign the default main database NAME to the NAME of the TEST attribute(see the codes difference).
This is fine because the documentation already describes that you need to have this structure of your settings file here
To reproduce the issue, create a test file in some django project that has authentication, a login page, and that uses an asgi and selenium or another web driver framework.
from channels.testing import ChannelsLiveServerTestCasefrom django.contrib.auth.models import User
class LiveTest(ChannelsLiveServerTestCase):serve_static = Truefixtures = [] # any fixtures you want to be loaded
Even though we have created a temp user in the test, Django will not let us log in. This because the Daphne server is pointed at the wrong database in the child process.
When we examine settings.DATABASES['default'] in the test file, we see that django returns this.
{'ENGINE': 'django.db.backends.sqlite3', 'NAME': '/Users/ashtonrobinson/cNode/testdatabase.sqlite3', 'USER': 'user','PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '5432', 'TEST': {'NAME':'/Users/ashtonrobinson/cNode/testdatabase.sqlite3', 'CHARSET': None, 'COLLATION': None, 'MIGRATE': True, 'MIRROR':None}, 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'CONN_MAX_AGE': 0, 'OPTIONS': {}, 'TIME_ZONE': None}
We see that the NAME field is correctly the test database, but this needs to be set when django is reloaded in the child process. This is what is being done by the updates to the code.
This fix refers to here
Currently, when a test class inherits from ChannelsLiveServerTestCase, all database changes that happen will be written to the default main database, not the test database that is created by the parent class--TransactionTestCase. This is the reason that fixtures are not currently referenced
When ChannelsLiveServerTestCase initiates a DaphneProcess, by calling this following line
self._server_process = self.ProtocolServerProcess(self.host, get_application)This instantiates a DaphneProcess object which is a multiprocessing.Process object which takes care of creating a new process. This uses the SpawnProcess of multiprocessing class on Windows and macOS. Linux uses the Fork method, but Fork causes problems. Spawn should be used only.Here is what is said about spawn.
The parent process starts a fresh python interpreter process. The child process will only inherit those resources necessaryto run the process objects run() method. In particular, unnecessary file descriptors and handles from the parent processwill not be inherited. Starting a process using this method is rather slow compared to using fork or forkserver. [Available onUnix and Windows. The default on Windows and macOS.]This means that django setup() is called and the settings file it reloaded. This means that `setting.DATABASES['default'] in the process that runs the Daphne server will point to the default database. This is incorrect, and will cause a leakage of all changes made by selenium or another testing framework.
Because ChannelsLiveServerTestCase inherits from TransactionTestCase, it it necessary that all functionality is retained. Therefore, we must point the django module at the test database in the the new process that is running Daphne so that we can correctly use the fixtures, and have the test database removed after testing is finished. Also, so that changes do not leak into the default database.
This is why, we reassign the default main database NAME to the NAME of the TEST attribute(see the codes difference). This is fine because the documentation already describes that you need to have this structure of your settings file here
To reproduce the issue, create a test file in some django project that has authentication, a login page, and that uses an asgi and selenium or another web driver framework.
from channels.testing import ChannelsLiveServerTestCasefrom django.contrib.auth.models import Userclass LiveTest(ChannelsLiveServerTestCase):serve_static = Truefixtures = [] # any fixtures you want to be loaded@classmethoddef setUpClass(cls) -> None:super().setUpClass()cls.driver = webdriver.Chrome()@classmethoddef tearDownClass(cls) -> None:super().tearDownClass()cls.driver.quit()def setUp(self):user = User.objects.create(username='temp')user.set_password('temp')def login(self, username:str, password:str):time.sleep(2)self.driver.get(self.live_server_url + '/')time.sleep(2)self.driver.get(self.live_server_url + '/login/')# print(settings.DATABASES['default'])user_input_field = #find user input fieldpassword_input_field = #find password input fielduser_input_field.send_keys(username)password_input_field.send_keys(password)time.sleep(3)login_button = #find login buttonlogin_button.click()time.sleep(3)def test_click(self):self.login('temp', 'temp')Even though we have created a temp user in the test, Django will not let us log in. This because the Daphne server is pointed at the wrong database in the child process.
When we examine
settings.DATABASES['default']in the test file, we see that django returns this.{'ENGINE': 'django.db.backends.sqlite3', 'NAME': '/Users/ashtonrobinson/cNode/testdatabase.sqlite3', 'USER': 'user','PASSWORD': 'password', 'HOST': 'localhost', 'PORT': '5432', 'TEST': {'NAME':'/Users/ashtonrobinson/cNode/testdatabase.sqlite3', 'CHARSET': None, 'COLLATION': None, 'MIGRATE': True, 'MIRROR':None}, 'ATOMIC_REQUESTS': False, 'AUTOCOMMIT': True, 'CONN_MAX_AGE': 0, 'OPTIONS': {}, 'TIME_ZONE': None}We see that the NAME field is correctly the test database, but this needs to be set when django is reloaded in the child process. This is what is being done by the updates to the code.