from playwright.sync_api import Playwright, sync_playwright


def run(playwright: Playwright) -> None:
    browser = playwright.chromium.launch(headless=False)
    context = browser.new_context(viewport={"width": 960, "height": 1080})
    page = context.new_page()
    page.goto("http://localhost:8000/docs")
    page.get_by_text("GET/items/Read Items").click()
    page.get_by_role("tab", name="Schema").click()

This works the same way as with Pydantic models. And it is actually achieved in the same way underneath, using Pydantic.

!!! info
    Keep in mind that dataclasses can't do everything Pydantic models can do.

    So, you might still need to use Pydantic models.

    But if you have a bunch of dataclasses laying around, this is a nice trick to use them to power a web API using FastAPI. 🤓

## Dataclasses in `response_model`

If something seems interesting and useful to your project, go ahead and check it, but otherwise, you might probably just skip them.

!!! tip

    # For coverage
    assert UploadFile.__get_pydantic_core_schema__(str, lambda x: None) == {}


@needs_pydanticv1
def test_union_scalar_list():
    # For coverage
    # TODO: there might not be a current valid code path that uses this, it would
    # potentially enable query parameters defined as both a scalar and a list
    # but that would require more refactors, also not sure it's really useful

    ```

Notice that we declare the type of `current_user` as the Pydantic model `User`.

This will help us inside of the function with all the completion and type checks.

!!! tip
    You might remember that request bodies are also declared with Pydantic models.

    Here **FastAPI** won't get confused because you are using `Depends`.

!!! check

Depending on your use case, you might prefer to use a different library, but if you asked me, I would probably suggest you try **Strawberry**.

Here's a small preview of how you could integrate Strawberry with FastAPI:

```Python hl_lines="3  22  25-26"

## Separating tests

In a real application, you probably would have your tests in a different file.

And your **FastAPI** application might also be composed of several files/modules, etc.

### **FastAPI** app file

Let's say you have a file structure as described in [Bigger Applications](bigger-applications.md){.internal-link target=_blank}:

```
.

.termynal-comment {
  color: #4a968f;
  font-style: italic;
  display: block;
}

.termy {
  /* For right to left languages */
  direction: ltr;
}

.termy [data-termynal] {
  white-space: pre-wrap;
}

a.external-link {
  /* For right to left languages */
  direction: ltr;
  display: inline-block;
}

a.external-link::after {
  /* \00A0 is a non-breaking space

from playwright.sync_api import Playwright, sync_playwright


def run(playwright: Playwright) -> None:
    browser = playwright.chromium.launch(headless=False)
    context = browser.new_context(viewport={"width": 960, "height": 1080})
    page = context.new_page()
    page.goto("http://localhost:8000/docs")
    page.get_by_text("GET/items/Read Items").click()
    page.get_by_role("button", name="Try it out").click()

## Create the tables

In this case, we are creating the tables in the same Python file, but in production, you would probably want to create them with Alembic, integrated with migrations, etc.

Here, this section would run directly, right before starting your **FastAPI** application.

* Create an `engine`.
* Create all the tables from the `metadata` object.

```Python hl_lines="25-28"
{!../../../docs_src/async_sql_databases/tutorial001.py!}
```