You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be a boon to developers if the test suite could be run more quickly. The obvious way to do this is by running them in parallel. There are a few blockers to doing this, notably the coverage checks built into our test_runner module. Another is concerns about thread-safety of various libraries (lxml, at least, was not thread-safe in the past; not sure about current versions).
During development, running without the coverage would often be adequate. A quick-and-dirty way to do this would be to launch each app's tests in its own process. This should avoid threading concerns.
A zeroth order attempt fails because we use a fixed name for the test database, but this should be relatively straightforward to resolve.
Tests pass for the first app dispatched, but the others bomb out at startup with errors that include the following. Adding a suffix to the test database would probably let them run. For real use, we'd want to be more thoughtful about handling i/o, of course.
Datatracker 12.26.4-dev test suite, 07 November 2024 03:13:26 PST:
Python 3.9.20 (main, Oct 19 2024, 19:39:41) [GCC 10.2.1 20210110].
Django 4.2.16, settings 'settings_test'
Changing TEMPLATES[0]['OPTIONS']['string_if_invalid'] to '' during testing
Changing INTERNAL_IPS to '[]' during testing.
Running an SMTP test server on 127.0.0.1:2033 to catch outgoing email.
Loading factory-boy random state from .factoryboy_random_state
Validating all HTML generated during the tests
Datatracker 12.26.4-dev test suite, 07 November 2024 03:13:26 PST:
Python 3.9.20 (main, Oct 19 2024, 19:39:41) [GCC 10.2.1 20210110].
Django 4.2.16, settings 'settings_test'
Changing TEMPLATES[0]['OPTIONS']['string_if_invalid'] to '' during testing
Changing INTERNAL_IPS to '[]' during testing.
Loading factory-boy random state from .factoryboy_random_state
Validating all HTML generated during the tests
Found 1 test(s).
Found 6 test(s).
Creating test database...
Datatracker 12.26.4-dev test suite, 07 November 2024 03:13:26 PST:
Got an error creating the test database: database "test_test.db" already exists
Type 'yes' if you would like to try deleting the test database 'test_test.db', or 'no' to cancel:
Description
It would be a boon to developers if the test suite could be run more quickly. The obvious way to do this is by running them in parallel. There are a few blockers to doing this, notably the coverage checks built into our test_runner module. Another is concerns about thread-safety of various libraries (lxml, at least, was not thread-safe in the past; not sure about current versions).
During development, running without the coverage would often be adequate. A quick-and-dirty way to do this would be to launch each app's tests in its own process. This should avoid threading concerns.
A zeroth order attempt fails because we use a fixed name for the test database, but this should be relatively straightforward to resolve.
Tests pass for the first app dispatched, but the others bomb out at startup with errors that include the following. Adding a suffix to the test database would probably let them run. For real use, we'd want to be more thoughtful about handling i/o, of course.
@holloway
Code of Conduct
The text was updated successfully, but these errors were encountered: