}

  /**
   * This is for covering a case where the ServiceManager would behave strangely if constructed with
   * no service under management. Listeners would never fire because the ServiceManager was healthy
   * and stopped at the same time. This test ensures that listeners fire and isHealthy makes sense.
   */
  public void testEmptyServiceManager() {
    Logger logger = Logger.getLogger(ServiceManager.class.getName());

  }

  /**
   * This is for covering a case where the ServiceManager would behave strangely if constructed with
   * no service under management. Listeners would never fire because the ServiceManager was healthy
   * and stopped at the same time. This test ensures that listeners fire and isHealthy makes sense.
   */
  public void testEmptyServiceManager() {
    Logger logger = Logger.getLogger(ServiceManager.class.getName());

Change Log
==========

## Version 5.3.2

_2025-11-18_

 *  Fix: Don't delay triggering timeouts. In Okio 3.16.0 we introduced a regression that caused
    timeouts to fire later than they were supposed to.

 *  Upgrade: [Okio 3.16.4][okio_3_16_4].


## Version 5.3.1

_2025-11-16_

This release is the same as 5.3.0. Okio 3.16.3 didn't have a necessary fix!

*  Upgrade: [Okio 3.16.3][okio_3_16_3].

    assertThat(logged.get(0).getThrown()).hasMessageThat().isEqualTo("You can't fire me, I quit.");
  }

  private static final class CancelPanickingFuture<V> extends AbstractFuture<V> {
    @Override
    public boolean cancel(boolean mayInterruptIfRunning) {
      setException(new Error("You can't fire me, I quit."));
      return false;
    }
  }

    assertThat(logged.get(0).getThrown()).hasMessageThat().isEqualTo("You can't fire me, I quit.");
  }

  private static final class CancelPanickingFuture<V> extends AbstractFuture<V> {
    @Override
    public boolean cancel(boolean mayInterruptIfRunning) {
      setException(new Error("You can't fire me, I quit."));
      return false;
    }
  }

Nous pouvons ensuite tester qu'il est bien utilisé.

## Lire un fichier `.env` { #reading-a-env-file }

Si vous avez de nombreux paramètres susceptibles de beaucoup changer, peut-être selon les environnements, il peut être utile de les placer dans un fichier, puis de les lire comme s'il s'agissait de variables d'environnement.

    """Represents a single Server-Sent Event.

    When `yield`ed from a *path operation function* that uses
    `response_class=EventSourceResponse`, each `ServerSentEvent` is encoded
    into the [SSE wire format](https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream)
    (`text/event-stream`).

    If you yield a plain object (dict, Pydantic model, etc.) instead, it is

* Lire ce que j'écris (ou me suivre) sur [**Dev.to**](https://dev.to/tiangolo) ou [**Medium**](https://medium.com/@tiangolo).
    * Lire d'autres idées, des articles, et découvrir des outils que j'ai créés.
    * Me suivre pour lire quand je publie quelque chose de nouveau.

## Tweeter à propos de **FastAPI** { #tweet-about-fastapi }

$ echo "Hello $Env:MY_NAME"

Hello Wade Wilson
```

</div>

////

## Lire des variables d'environnement en Python { #read-env-vars-in-python }

Vous pouvez également créer des variables d'environnement **en dehors** de Python, dans le terminal (ou par tout autre moyen), puis les **lire en Python**.

Par exemple, vous pouvez avoir un fichier `main.py` contenant :

```Python hl_lines="3"
import os

Lorsque vous avez besoin d'exécuter `lifespan` dans vos tests, vous pouvez utiliser `TestClient` avec une instruction `with` :

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

Vous pouvez lire plus de détails dans [« Exécuter lifespan dans les tests sur le site de documentation officiel de Starlette. »](https://www.starlette.dev/lifespan/#running-lifespan-in-tests)