Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support parallel tests with external database

Abierto
  • ¿Algo no está bien?
#474 4 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
32/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
postgresql, python
Área
databases, testing-qa

Línea de trabajo

Comienza rastreando la ejecución paralela actual basada en fork de mutmut y cómo se escriben los resultados de las mutaciones en archivos foo.py.meta. Compara el comportamiento de los workers y de los session-fixtures descrito en la documentación de pytest-xdist. Se considera terminado cuando los workers paralelos pueden inicializar bases de datos PostgreSQL aisladas, ejecutar mutaciones sin conflictos y agregar los resultados de forma segura.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)
Lenguaje dominante
Python
Estrellas
1.5k
Forks
181
Merge medio
2 d 7 h
PR fusionados (30 d)
1

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de boxed/mutmut

Todos los issues de boxed/mutmut

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.