Opened 13 days ago

Last modified 3 days ago

#28790 new Cleanup/optimization

Document how to avoid running certain test classes in parallel

Reported by: Tobias Krönke Owned by: nobody
Component: Documentation Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by Tobias Krönke)

In PR https://github.com/django/django/pull/9342 I propose to enable users to mark tests for non-parallel execution. In this way, they don't have to make sure, that all their tests are properly isolated. This is useful, if you work with other external storages like e.g. solr and django-haystack.

Change History (5)

comment:1 Changed 13 days ago by Tobias Krönke

Description: modified (diff)

comment:2 Changed 13 days ago by Tobias Krönke

Description: modified (diff)

comment:3 Changed 13 days ago by Tim Graham

Isn't this is already provided by ba813864870d63de1d1679271c38a3c15e94e934? It could probably be documented if needed.

comment:4 Changed 12 days ago by Tobias Krönke

I don't want to be too eager for this to be merged. I probably wouldn't have looked any further had I known this Mixin. Still I would like to point out some advantages of my solution:

  • Less complex to use
  • Less complex implementation (especially no lock files involved)
  • More efficient, if you have only 1 shared resource (no concurrent waits for the locked file)

Of course I also see the advantage of the existing mixin, that you can use different lock files for different shared resources if you have many. A hint in the docs would be quite pleasant.

So, your call ;-)

comment:5 Changed 3 days ago by Tim Graham

Component: Testing frameworkDocumentation
Has patch: unset
Summary: Provide a mixin to run certain test classes not in parallelDocument how to avoid running certain test classes in parallel
Triage Stage: UnreviewedAccepted
Type: New featureCleanup/optimization

I guess it's better to document the existing class rather than add another one unless the new implementation is preferred for some reason.

Note: See TracTickets for help on using tickets.
Back to Top