Cuando necesitas que `lifespan` se ejecute en tus tests, puedes usar el `TestClient` con un statement `with`:

{* ../../docs_src/app_testing/tutorial004_py39.py hl[9:15,18,27:28,30:32,41:43] *}


Puedes leer más detalles sobre ["Ejecutar lifespan en tests en el sitio oficial de documentación de Starlette."](https://www.starlette.dev/lifespan/#running-lifespan-in-tests)

## Llama a `uvicorn` { #call-uvicorn }

En tu aplicación de FastAPI, importa y ejecuta `uvicorn` directamente:

{* ../../docs_src/debugging/tutorial001_py39.py hl[1,15] *}

### Acerca de `__name__ == "__main__"` { #about-name-main }

El objetivo principal de `__name__ == "__main__"` es tener algo de código que se ejecute cuando tu archivo es llamado con:

<div class="termy">

```console
$ python myapp.py
```

en segundo plano y no necesariamente necesitas que se ejecute por el mismo proceso (por ejemplo, no necesitas compartir memoria, variables, etc.), podrías beneficiarte del uso de otras herramientas más grandes como <a href="https://docs.celeryq.dev" class="external-link" target="_blank">Celery</a>.

Tienden a requerir configuraciones más complejas, un gestor de cola de mensajes/trabajos, como RabbitMQ o Redis, pero te permiten ejecutar tareas en segundo plano en múltiples procesos, y especialmente,...

Solo el código anterior e incluyendo la declaración `yield` se ejecuta antes de crear un response:

{* ../../docs_src/dependencies/tutorial007_py39.py hl[2:4] *}

El valor generado es lo que se inyecta en *path operations* y otras dependencias:

{* ../../docs_src/dependencies/tutorial007_py39.py hl[4] *}

El código posterior a la declaración `yield` se ejecuta después del response:

Para lograr esto, normalmente tendrás un **programa separado** que se asegurará de que tu aplicación se ejecute al iniciarse. Y en muchos casos, también se asegurará de que otros componentes o aplicaciones se ejecuten, por ejemplo, una base de datos.

### Herramientas de Ejemplo para Ejecutar al Iniciar { #example-tools-to-run-at-startup }

Algunos ejemplos de las herramientas que pueden hacer este trabajo son:

En el camino de la request, el middleware más externo se ejecuta primero.

En el camino de la response, se ejecuta al final.

Por ejemplo:

```Python
app.add_middleware(MiddlewareA)
app.add_middleware(MiddlewareB)
```

Esto da como resultado el siguiente orden de ejecución:

## Sobrescribir dependencias durante las pruebas { #overriding-dependencies-during-testing }

Hay algunos escenarios donde podrías querer sobrescribir una dependencia durante las pruebas.

No quieres que la dependencia original se ejecute (ni ninguna de las sub-dependencias que pueda tener).

Usando `Depends(scope="function")`, el código de salida después de `yield` se ejecuta justo después de que la *path operation function* termina, antes de que la response se envíe de vuelta al cliente.

Y al usar `Depends(scope="request")` (el valor por defecto), el código de salida después de `yield` se ejecuta después de que la response es enviada.

    * Para que esto funcione, un componente (programa) **único** que se ejecute en el servidor, escuchando en la **dirección IP pública**, debe tener **todos los certificados HTTPS** en el servidor.
* **Después** de obtener una conexión segura, el protocolo de comunicación sigue siendo **HTTP**.

///

Alternativamente, HTTPS podría ser manejado por un proveedor de la nube como uno de sus servicios (mientras que la aplicación aún se ejecuta en un contenedor).

## Ejecutar en el Inicio y Reinicios { #running-on-startup-and-restarts }

Normalmente hay otra herramienta encargada de **iniciar y ejecutar** tu contenedor.

Podría ser **Docker** directamente, **Docker Compose**, **Kubernetes**, un **servicio en la nube**, etc.