# Estándares de pruebas

Esta sección describe la forma en que se realizan las pruebas en los diferentes servicios e interfaces de usuario de los proyectos de Decentraland.

Las palabras clave "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" y "OPTIONAL" en este documento deben interpretarse según lo descrito en [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).

## Resumen

Las pruebas son una parte crítica de nuestro proceso de desarrollo. Mantenemos altos estándares de cobertura y calidad de pruebas en todos nuestros proyectos. Esta documentación ofrece pautas completas para:

* [**Escribir pruebas**](/contributor/contributor-es/guias-para-colaboradores/testing-standards/writing-tests.md) - Principios y patrones generales para escribir pruebas mantenibles y claras
* [**Probar interfaces de usuario**](/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-uis.md) - Probar componentes React, sagas de Redux, reducers, selectores y creadores de acciones
* [**Probar servicios (Well-Known-Component)**](/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-services-wkc.md) - Probar servicios modulares construidos con la arquitectura well-known-component
* [**Probar servicios (Obsoleto)**](/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-services-deprecated.md) - Enfoque heredado para probar servicios (como referencia)
* [**Pruebas de extremo a extremo**](/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-e2e.md) - Pruebas E2E con Cypress (Trabajo en progreso)

## Filosofía de pruebas

Nuestro enfoque de pruebas enfatiza:

* **Claridad** - Las pruebas deben ser autoexplicativas y fáciles de entender
* **Mantenibilidad** - Las pruebas deben ser fáciles de actualizar cuando cambian los requisitos
* **Aislamiento** - Cada prueba debe ejecutarse de forma independiente sin afectar a las demás
* **Cobertura** - Todos los caminos críticos y casos límite deben ser probados
* **Valor** - Las pruebas deben proporcionar confianza de que el código funciona según lo previsto

## Enlaces rápidos

* [Cómo describir contextos con `describe`](/contributor/contributor-es/guias-para-colaboradores/testing-standards/writing-tests.md#describing-and-building-context)
* [Cómo escribir expectativas con `it`](/contributor/contributor-es/guias-para-colaboradores/testing-standards/writing-tests.md#describing-expectations-and-executing-code)
* [Qué probar y cuándo](/contributor/contributor-es/guias-para-colaboradores/testing-standards/writing-tests.md#what-to-test)
* [Cuándo y cómo simular (mock)](/contributor/contributor-es/guias-para-colaboradores/testing-standards/writing-tests.md#when-to-mock)

## Normas relacionadas

* [Gestión de dependencias](/contributor/contributor-es/guias-para-colaboradores/dependency-management.md) - Gestión de dependencias npm y peerDependencies
* [Estándares de UI](https://github.com/decentraland/docs/blob/main/contributor/contributor-guides/ui-standards/README.md) - Patrones de Redux y RTK Query
* [Documentación de API](/contributor/contributor-es/guias-para-colaboradores/api-documentation.md) - Estándares de documentación OpenAPI


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.