# 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**](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/writing-tests) - Principios y patrones generales para escribir pruebas mantenibles y claras
* [**Probar interfaces de usuario**](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-uis) - Probar componentes React, sagas de Redux, reducers, selectores y creadores de acciones
* [**Probar servicios (Well-Known-Component)**](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-services-wkc) - Probar servicios modulares construidos con la arquitectura well-known-component
* [**Probar servicios (Obsoleto)**](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-services-deprecated) - Enfoque heredado para probar servicios (como referencia)
* [**Pruebas de extremo a extremo**](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/testing-standards/testing-e2e) - 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`](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/writing-tests#describing-and-building-context)
* [Cómo escribir expectativas con `it`](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/writing-tests#describing-expectations-and-executing-code)
* [Qué probar y cuándo](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/writing-tests#what-to-test)
* [Cuándo y cómo simular (mock)](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/writing-tests#when-to-mock)

## Normas relacionadas

* [Gestión de dependencias](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/dependency-management) - 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](https://docs.decentraland.org/contributor/contributor-es/guias-para-colaboradores/api-documentation) - Estándares de documentación OpenAPI