Separate Selenium and Django tests

[PantelisElinas]

When running all the tests, Selenium and Django together using the command,

python manage.py test catalog.tests

cause the Selenium tests to fail with a user login error (even though the Django tests run without problems)

django.db.utils.IntegrityError: duplicate key value violates unique constraint "auth_user_username_key" DETAIL: Key (username)=(user1) already exists.

The Selenium tests run correctly if invoked separately using the command,

python manage.py test catalog.tests.test_selenium_flaggingcomments

@Zhenghao-Zhao wrote about this issue,

Here is what I found that might be related to this issue:

"If your tests rely on database access such as creating or querying models, be sure to create your test classes as subclasses of django.test.TestCase rather than unittest.TestCase. Using unittest.TestCase avoids the cost of running each test in a transaction and flushing the database, but if your tests interact with the database their behavior will vary based on the order that the test runner executes them. This can lead to unit tests that pass when run in isolation but fail when run in a suite." (https://docs.djangoproject.com/en/3.0/topics/testing/overview/)

My understanding is that in django.test.testcase all tests run with a mockup database, where as in unittest.testcase it runs in the same production database (default). Running them at the same time might have mixed the database those tests are run in therefore the error. However, after I changed my base test class to django.test.TestCase, I still got the same issue.

This ticket is about getting around the above problem by separating the Selenium and Django tests into separate folders so that we can run them separately.

[Zhenghao-Zhao]

Update: The problem seems to be when log in from the browser it is using the production database. The users we create in the selenium tests, subclassed from django.test.TestCase or django.contrib.staticfiles.testing.StaticLiveServerTestCase are stored in their own database which has the lifecycle as the tests themselves.

I have verified this by creating a user with the same credential in the production database as the ones created in the tests, and I was able to log in.

[Zhenghao-Zhao]

Update: Turns out the problem was with the port number I was using which differs from the port the test database was using.