* hard dependencies: dependencias obligatorias (do not translate to "dependencias duras")
* locking: locking (do not translate to "bloqueo")
* testing (as in software testing): escribir pruebas (do not translate to "probar")
* code base: code base (do not translate to "base de código")
* default: por defecto (do not translate to "predeterminado")

<small>* estimación basada en pruebas con un equipo de desarrollo interno, construyendo aplicaciones de producción.</small>

## Sponsors { #sponsors }

<!-- sponsors -->

### Sponsor Keystone { #keystone-sponsor }

/// tip | Consejo

Si quieres llamar a funciones `async` en tus pruebas además de enviar requests a tu aplicación FastAPI (por ejemplo, funciones asincrónicas de bases de datos), echa un vistazo a las [Pruebas Asincrónicas](../advanced/async-tests.md) en el tutorial avanzado.

///

## Separando pruebas { #separating-tests }

En una aplicación real, probablemente tendrías tus pruebas en un archivo diferente.

## 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).

# Escribir pruebas para una base de datos { #testing-a-database }

Puedes estudiar sobre bases de datos, SQL y SQLModel en la [documentación de SQLModel](https://sqlmodel.tiangolo.com/). 🤓

Hay un mini [tutorial sobre el uso de SQLModel con FastAPI](https://sqlmodel.tiangolo.com/tutorial/fastapi/). ✨

{* ../../docs_src/settings/app02_an_py310/main.py hl[17,19:21] *}

### Configuraciones y pruebas { #settings-and-testing }

Luego sería muy fácil proporcionar un objeto de configuraciones diferente durante las pruebas al crear una sobrescritura de dependencia para `get_settings`:

{* ../../docs_src/settings/app02_an_py310/test_main.py hl[9:10,13,21] *}

#### Un ataque "profesional" { #a-professional-attack }

Por supuesto, los atacantes no intentarían todo esto a mano, escribirían un programa para hacerlo, posiblemente con miles o millones de pruebas por segundo. Y obtendrían solo una letra correcta adicional a la vez.

# Archivo de prueba de LLM { #llm-test-file }

Este documento prueba si el <abbr title="Large Language Model - Modelo de lenguaje grande">LLM</abbr>, que traduce la documentación, entiende el `general_prompt` en `scripts/translate.py` y el prompt específico del idioma en `docs/{language code}/llm-prompt.md`. El prompt específico del idioma se agrega al final de `general_prompt`.

Luego contribuí a este, para hacerlo totalmente compatible con JSON Schema, para soportar diferentes maneras de definir declaraciones de restricciones, y para mejorar el soporte de los editores (chequeo de tipos, autocompletado) basado en las pruebas en varios editores.

Durante el desarrollo, también contribuí a [**Starlette**](https://www.starlette.dev/), el otro requisito clave.

## Desarrollo { #development }

    $ mvn dbflute:freegen
    $ mvn license:format

### Pruebas de Integración

Inicia el servidor Fess y ejecuta el siguiente comando:

    $ mvn test -P integrationTests -Dtest.fess.url="http://localhost:8080" -Dtest.search_engine.url="http://localhost:9201"

Para ejecutar un único caso de prueba, puedes usar: