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

Write developer documentation on writing tests

Abierto
  • ¿Algo no está bien?
#169 2 comentarios 0 reacciones 1 asignado Ver en GitHub

@PGijsbers ya está trabajando en esto.

Desde el 16/7/2024.

  • #278 de @PredictiveManish — cerrado sin fusionar

Evaluación

Este issue todavía no se ha evaluado.

Descripción

documentation

After some reading and testing, I found that I think I want to stick with the following strategy for now:

  1. Migration testing, which tests the python api responses against the php ones, when set up against the same pre-populated database. This is so we ensure correctness for migration, and have explicit documentation about the differences (in the unit tests, though they should also end up on the migration page)
  2. Integration testing for expected paths. Simple tests that test the full Python stack, including FastAPI client, dependency injection, and database interactions. For these tests the data will be added to the database on a per-test level. This makes it easy and fast to run tests by any developer- no management of test database state needed. From measurements I did find that creating the TestClient for FastAPI has considerable overhead (approx. 60ms per test). For this reason, we limit this to one test per kind of expected response. E.g., for get_flow: one with a returned flow, one without a result.
  3. Test database functions directly on a database which have items inserted on a per-test level. This is still surprisingly responsive, so there is no need to mock anything out.
  4. Test the broader input/output of the different API methods by calling the Python functions directly instead of through the TestClient. This is so we can test more different scenarios, while being fast. It also ensures that if tests fail at the API level (point 1) but not here, we know it is due to changes of FastAPI its configuration. Database calls at this level can be mocked, to better isolate the input/output processing of this function. I have some consideration of not mocking anything out here, to avoid the extra boilerplate. The database fixtures are pretty performant (~2ms).

This is not set in stone. Perhaps we should not even separate tests out this much, and only factoring out the FastAPI layer is enough. If someone with more experience happens to read this, feel free to leave your thoughts :)

Lenguaje dominante
Python
Estrellas
17
Forks
50
Sin PR fusionados en 30 d

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Tiene una plantilla de pull request
  • Sin guía de contribución

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 openml/server-api

Todos los issues de openml/server-api

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.