Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Support parallel tests with external database

Aperta
  • Qualcosa non va?
#474 4 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 3 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
32/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Attiva
Stack tecnologico
postgresql, python
Ambito
databases, testing-qa

Direzione di ricerca

Inizia tracciando l’attuale esecuzione parallela basata su fork di mutmut e il modo in cui i risultati delle mutazioni vengono scritti nei file foo.py.meta. Confronta il comportamento dei worker e dei session-fixture descritto nella documentazione di pytest-xdist. Il lavoro è completo quando i worker paralleli possono inizializzare database PostgreSQL isolati, eseguire mutazioni senza conflitti e aggregare i risultati in modo sicuro.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Similar to pytest-xdist: https://pytest-xdist.readthedocs.io/en/stable/how-to.html

I'm not sure yet how to implement this in mutmut, as the pytest setup is different (in pytest-xdist, session fixtures are run once per worker. Not sure how we could replicate this use case in mutmut)

I have a project which connects to a local postgres instance for integration tests. When running tests in parallel, they should connect to different databases on this instance, otherwise they would conflict with each other (e.g. test A deletes data from some table, while test B tries to read from this table). This means I currently cannot run these tests with mutmut.

The setup with pytest-xdist is:

  1. start e.g. 12 processes with PYTEST_XDIST_WORKER set to gw1, gw2, ..., gw12`
  2. for each process, it runs the pytest session fixture to setup the database
    2.1. The fixture connects to postgres and creates a database test_db_{PYTEST_XDIST_WORKER}
    2.2. Afterwards, we have 12 different databases
  3. When running a test, it runs against the test_db_{PYTEST_XDIST_WORKER} database

Therefore, each worker uses its own database.

I think something like step (1) would be rather straightforward: We use fork and do not have explicit workers, but we run at most n processes in parallel. We could create n ids, keep track of which ids are still free, and everytime we fork another process we take one of the free ids.

However, I'm not sure how we would go about running session fixtures once per "worker". I suppose, we would could:

  1. spawn (and not fork) 12 worker processes
  2. set MUTMUT_WORKER_1/2/.../12
  3. In each process run the complete test suite / an init method (for caching and running the database setup fixtures)
  4. Split the mutants across the workers (or use a multiprocessing queue/...)
  5. Inside of the worker, we sequentially run a single fork to create isolated copies of the worker process (with everything already setup) and run tests for mutations there
  6. Workers write their results into a results queue and the main process saves the stats in files (we should not write the foo.py.meta files from different processes)
Lingua principale
Python
Stelle
1.5k
Fork
182
Merge medio
2g 14h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di boxed/mutmut

Tutte le issue di boxed/mutmut

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.